(Microsoft Word - Ostrn\341d_Bezpe\350nos\235 a mana\236ment IS_skript\341_v_1_11.doc)

Prepis

1 Bezpečnosť a manažment informačných systémov Ondrej Strnád SLOVENSKÁ TECHNICKÁ UNIVERZITA V BRATISLAVE Fakulta informatiky a informačných technológií 1

2 Obsah POUŽÍVANÉ SKRATKY VYSVETLENIE VYBRANÝCH POJMOV PREHĽAD POUŽITEJ LITERATÚRY ÚVOD MANAŽMENT A INFORMAČNÉ PROCESY INFORMÁCIA INFORMAČNÉ PROCESY MANAŽMENT INFORMAČNÝ SYSTÉM A INFORMAČNÁ TECHNOLÓGIA ŽIVOTNÝ CYKLUS IS FÁZY ŽIVOTNÉHO CYKLU IS MODELY ŽIVOTNÉHO CYKLU IS BUDOVANIE PODNIKOVÉHO INFORMAČNÉHO SYSTÉMU POTREBA ZAVEDENIA NOVÉHO INFORMAČNÉHO SYSTÉMU PRÍPRAVA A REALIZÁCIA PROJEKTU ZAMERANÉHO NA VYBUDOVANIE IS Zaradenie projektu IS do rozvojového plánu Posúdenie vykonateľnosti projektu IS Zaistenie podpory pre projekt IS Formulovanie rozsahu projektu Návrh riadenia realizácie projektu Vedenie projektu Vedúci RKP Metodik projektu Právomoci a ich zrozumiteľnosť v rámci vedenia projektu Zabezpečenie primeraných podmienok na riešenie projektu Organizačné zaistenie Personálne zaistenie Finančné zaistenie Technické zaistenie Kontrolná činnosť Príprava a realizácia projektu Poslanie RKP vo fáze prípravy Požiadavky podniku na IS Dodávka IS špecializovanou firmou Definovanie HW a SW platformy IS Rozhodnutie o dodávateľovi IS Architektúra a topológia systému Typové riešenie Výberové konanie Zmluva s dodávateľom Implementácia IS Projekt realizácie IS Základná štruktúra realizačného projektu Úvodná štúdiá Určenie postupov Spôsob realizácie Etapa Začatie projektu Etapa Návrh realizácie Etapa Implementácia Etapa Skúšobná prevádzka Personálne zabezpečenie projektu Realizačné tímy RKP Dokumentácia riešenia a postupu prác Zabezpečenie infraštruktúry Súčinnosť dodávateľa s podnikom Súčinnosť s inými podnikmi Určenie typov používateľov nového IS a ich funkcií

3 Školenie používateľov Vypracovanie interných noriem pre prevádzku IS a bezpečnostných noriem Postupné zavádzanie komponentov IS Monitorovanie priebehu implementácie Testovanie Akceptácia systému Zmenové konanie Odovzdávanie modulov IS Prevádzka, údržba a rozvoj IS Pozícia podnikových útvarov pri prevádzke, údržbe a rozvoji IS Útvar IT Ďalšie podnikové útvary Pracoviská závodov a pobočiek Bezpečnosť IS a jeho prevádzky Súčinnosť s dodávateľom po ukončení implementácie Reklamácie a nové požiadavky Ponuka úprav od dodávateľa Priebežná inovácia dodávateľom PLÁNOVANIE A MANAŽMENT PROCESU BUDOVANIA IS RÁMCOVÝ OPIS FÁZY DETAILNÝ OPIS FÁZY Inovačný zámer Plánovanie procesu budovania IS Určenie cieľov IS Vypracovanie štúdie IS Plán budovania IS Riadenie projektu Riešenie bezpečnosti IS DOKUMENTY VZNIKAJÚCE V RÁMCI FÁZY METÓDY URČENIA CIEĽOV BUDOVANIA IS Metóda funkčnej dekompozície Metóda kritických faktorov úspechu Metóda činnosti SSM- Soft Systems Methodology Metóda alternatívnych budúcich scenárov VYPRACOVANIE KONCEPČNÉHO MODELU IS Dátový model vysokej úrovne Návrh štruktúry IS Návrh technického riešenia IS ZODPOVEDNOSŤ ZA REALIZÁCIU FÁZY ANALÝZA IS RÁMCOVÝ OPIS FÁZY DETAILNÝ OPIS FÁZY Etapy realizácie fázy Analýza požiadaviek používateľov IS Model budúceho IS Špecifikácia IS Technická špecifikácia IS Opis vybraných metód vhodných pre uplatnenie v rámci analýzy IS Vypracovanie Plánu akceptačného testovania IS Validácia výsledkov analýzy IS Analytický projekt IS Plán akceptačných testov Štruktúra plánu akceptačných testov Druhy akceptačných testov Riešenie bezpečnosti IS Analýza a manažment rizík IS Analýza stavu implementácie bezpečnostných opatrení v praxi Bezpečnostné testy zahrnuté do akceptačného testovania IS Možné prístupy k realizácii fázy DOKUMENTY VZNIKAJÚCE V RÁMCI FÁZY PODMIENKY ZAČATIA A UKONČENIA FÁZY114 3

4 6.5 ZODPOVEDNOSŤ ZA REALIZÁCIU FÁZY PROJEKTOVANIE IS RÁMCOVÝ OPIS FÁZY DETAILNÝ OPIS FÁZY Návrh architektúry Návrh logiky modulov Riešenie bezpečnosti IS Vypracovanie bezpečnostnej dokumentácie IS Vypracovanie plánu bezpečnostných testov realizovaných v rámci integračného testovania DOKUMENTY VZNIKAJÚCE V RÁMCI FÁZY PODMIENKY ZAČATIA A UKONČENIA FÁZY ZODPOVEDNOSŤ ZA REALIZÁCIU FÁZY VÝVOJ SW RÁMCOVÝ OPIS FÁZY DETAILNÝ OPIS FÁZY Kódovanie - programovanie Testovanie programov Vytvorenie dokumentácie k programom Vytvorenie používateľskej dokumentácie Špecifikácia testovania modulov Špecifikácia integračného testovania IS Riešenie bezpečnosti IS Dohľad nad implementáciou bezpečnostných opatrení v aplikačnom softvéri Vypracovanie bezpečnostných príručiek DOKUMENTY VZNIKAJÚCE V RÁMCI FÁZY PODMIENKY ZAČATIA A UKONČENIA FÁZY ZODPOVEDNOSŤ ZA REALIZÁCIU FÁZY BUDOVANIE HW A SW PLATFORMY IS RÁMCOVÝ OPIS FÁZY DETAILNÝ OPIS FÁZY Rozpracovanie architektúry a topológie IS Vytvorenie plánu dodávok a rozmiestnenia HW Rozmiestnenie HW Riešenie bezpečnosti IS Dohľad nad dodávkou HW a SW Dohľad nad inštalovaním HW a SW Dohľad nad nastavovaním bezpečnostných parametrov OS, DB, aplikácií, sieťového prostredia Dohľad nad vytváraním používateľov a ich prístupových práv Dohľad nad fyzickou a objektovou bezpečnosťou DOKUMENTY VZNIKAJÚCE V RÁMCI FÁZY PODMIENKY ZAČATIA A UKONČENIA FÁZY ZODPOVEDNOSŤ ZA REALIZÁCIU FÁZY INTEGRÁCIA A TESTOVANIE IS RÁMCOVÝ OPIS FÁZY DETAILNÝ OPIS FÁZY Integrácia a testovanie modulov Integrácia a testovanie IS Špecifikácia konfigurácie systému Riešenie bezpečnosti IS Realizácia bezpečnostných testov zahrnutých do integračného testovania Dohľad nad konfiguráciou systému DOKUMENTY VZNIKAJÚCE V RÁMCI FÁZY Protokol o testovaní modulov Protokol o integrácii a testovaní systému Konfigurácia systému PODMIENKY ZAČATIA A UKONČENIA FÁZY ZODPOVEDNOSŤ ZA REALIZÁCIU FÁZY

5 11 AKCEPTAČNÉ TESTOVANIE IS RÁMCOVÝ OPIS FÁZY DETAILNÝ OPIS FÁZY Vlastné akceptačné testovanie Špecifikácia akceptačných testov Nainštalovaný integrovaný IS Konfigurácia systému Testovacie dáta a testovacie skripty Testovací tím Plán akceptačných testov Zaškoľovanie používateľov Odovzdávanie IS zadávateľovi Riešenie bezpečnosti IS Realizácia bezpečnostných testov zahrnutých do akceptačného testovania Dohľad nad zaškolením používateľov Dohľad nad protokolárnym prevzatím IS do rutinnej prevádzky DOKUMENTY VZNIKAJÚCE V RÁMCI FÁZY Protokol o akceptačnom testovaní Protokol o zaškolení používateľov systému Odovzdávací a preberací protokol PODMIENKY ZAČATIA A UKONČENIA FÁZY ZODPOVEDNOSŤ ZA REALIZÁCIU FÁZY PREVÁDZKA A ÚDRŽBA IS RÁMCOVÝ OPIS FÁZY DETAILNÝ OPIS FÁZY Prevádzka IS Riadenie zmien Správa konfigurácií a systémovej dokumentácie Zabezpečenie ochrany a bezpečnosti IS DOKUMENTY VZNIKAJÚCE V RÁMCI FÁZY PODMIENKY ZAČATIA A UKONČENIA FÁZY ZODPOVEDNOSŤ ZA REALIZÁCIU FÁZY RIADENIE KVALITY IS ZÁKLADNÉ NORMY PRE RIADENIE KVALITY ISO/IEC SYSTÉM MANAŽÉRSTVA KVALITY Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov POŽIADAVKY NA DOKUMENTÁCIU Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov PLÁNOVANIE SYSTÉMU RIADENIA KVALITY Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov PRESKÚMAVANIE SYSTÉMU MANAŽMENTOM Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov KOMPETENTNOSŤ, POVEDOMIE A PRÍPRAVA PRACOVNÍKOV Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov INFRAŠTRUKTÚRA Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov PLÁNOVANIE REALIZÁCIE PRODUKTU Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov Životný cyklus softvéru Plánovanie kvality URČENIE POŽIADAVIEK TÝKAJÚCICH SA PRODUKTU

6 Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov PRESKÚMAVANIE POŽIADAVIEK NA PRODUKT Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov Záujmy organizácie Riziká Predstaviteľ zákazníka KOMUNIKÁCIA SO ZÁKAZNÍKOM Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov Komunikácia so zákazníkom počas vývoja Komunikácia so zákazníkom počas prevádzky a udržiavania softvéru PLÁNOVANIE NÁVRHU A VÝVOJA Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov Plánovanie návrhu a vývoja Preskúmavanie, verifikácia a validácia Rozohrania VSTUPY DO NÁVRHU A VÝVOJA Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov VÝSTUPY Z NÁVRHU A VÝVOJA Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov PRESKÚMAVANIE NÁVRHU A VÝVOJA Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov VERIFIKÁCIA NÁVRHU A VÝVOJA Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov VALIDÁCIA NÁVRHU A VÝVOJA Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov Validácia Testovanie RIADENIE ZMIEN NÁVRHU A VÝVOJA Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov PROCES NAKUPOVANIA Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov Nakupované produkty Kontrola nakupovaných produktov INFORMÁCIE O NAKUPOVANÍ Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov VERIFIKÁCIA NAKÚPENÉHO PRODUKTU Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov VÝROBA A POSKYTOVANIE SLUŽIEB V OBLASTI SOFTVÉRU Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov Tvorba softvéru a služby Zostavenie a vydanie Kopírovanie Dodanie Inštalácia Prevádzka Udržiavanie VALIDÁCIA PROCESOV VÝROBY A POSKYTOVANIA SLUŽIEB Požiadavka podľa ISO 9001:

7 Návod pre oblasť softvérových produktov IDENTIFIKÁCIA A SLEDOVATEĽNOSŤ Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov Prehľad Riadenie konfigurácie Sledovateľnosť MAJETOK ZÁKAZNÍKA Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov OCHRANA PRODUKTU Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov RIADENIE PRÍSTROJOV NA MONITOROVANIE A MERANIE Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov VŠEOBECNÉ POŽIADAVKY NA MERANIE, ANALÝZU A ZLEPŠOVANIE Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov SPOKOJNOSŤ ZÁKAZNÍKA Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov INTERNÝ AUDIT Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov MONITOROVANIE A MERANIE PROCESOV Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov RIADENIE NEZHODNÉHO PRODUKTU Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov ANALÝZA ÚDAJOV Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov TRVALÉ ZLEPŠOVANIE Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov NÁPRAVNÁ ČINNOSŤ Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov PREVENTÍVNA ČINNOSŤ Požiadavka podľa ISO 9001: Návod pre oblasť softvérových produktov INFORMAČNÁ BEZPEČNOSŤ BEZPEČNOSTNÉ PRVKY Aktíva Hrozby Zraniteľnosť Dopad Riziko Zvyškové riziko Bezpečnostné opatrenia Obmedzenia Vzťahy medzi bezpečnostnými prvkami ANALÝZA A MANAŽMENT RIZÍK ANALÝZA RIZÍK Prístupy k analýze rizík Základný prístup Neformálny prístup

8 Detailná analýza Kombinovaný prístup MANAŽMENT RIZÍK Výber bezpečnostných opatrení Výber bezpečnostných opatrení podľa typu a charakteristiky IS Identifikácia typu systému Identifikácia fyzických/environmentálnych podmienok Ohodnotenie existujúcich/plánovaných opatrení Ohodnotenie bezpečnostných požiadaviek a hrozieb Strata dôvernosti Strata integrity Strata dostupnosti Strata zodpovednosti Strata autenticity Strata spoľahlivosti Výber bezpečnostných opatrení pre pokrytie bezpečnostných záujmov Bezpečnostné opatrenia pre dôvernosť (utajenie) Bezpečnostné opatrenia pre integritu Bezpečnostné opatrenia pre dostupnosť Bezpečnostné opatrenia pre osobnú zodpovednosť, autentickosť a spoľahlivosť Výber opatrení podľa podrobných ohodnotení NÁSTROJE PRE ANALÝZU A MANAŽMENT RIZÍK IS RiskPAC CRAMM COBRA Analýza a manažment rizík IS nástrojom CRAMM BEZPEČNOSTNÁ DOKUMENTÁCIA IS BEZPEČNOSTNÁ POLITIKA IS Dokument bezpečnostnej politiky BEZPEČNOSTNÝ ZÁMER IS BEZPEČNOSTNÝ PROJEKT BEZPEČNOSTNÉ SMERNICE HAVARIJNÝ PLÁN A PLÁN OBNOVY ČINNOSTI Manažment kontinuity činnosti Analýza dopadov havárie na spoločnosť Zostavovanie a implementovanie plánov kontinuity činnosti Štruktúra plánovania kontinuity činnosti Zostavovanie plánov obnovy činnosti Príprava podkladov pre zostavenie plánu obnovy Vytvorenie plánu obnovy Reakčná fáza (stav núdze) Krízový manažment Riadiace centrum Záchrana majetku a ohodnotenie škody Koordinácia obnovy Fáza obnovy Fáza návratu Riadiaci tím návratu Testovanie plánov Údržba a prehodnocovanie plánov MANAŽMENT BEZPEČNOSTI IS VO FÁZACH ŽIVOTNÉHO CYKLU BEZPEČNOSŤ IS VO FÁZE PLÁNOVANIA A RIADENIA BEZPEČNOSŤ IS VO FÁZE ANALÝZY IS Analýza a manažment rizík IS Analýza stavu implementácie bezpečnostných opatrení v praxi Bezpečnostné testy zahrnuté do akceptačného testovania IS BEZPEČNOSŤ IS VO FÁZE PROJEKTOVANIA Vypracovanie bezpečnostnej dokumentácie IS Vypracovanie plánu bezpečnostných testov realizovaných v rámci integračného testovania BEZPEČNOSŤ IS VO FÁZE VÝVOJA SOFTVÉRU IS Dohľad nad implementáciou bezpečnostných opatrení v aplikačnom softvéri Vypracovanie bezpečnostných príručiek

9 17.5 BEZPEČNOSŤ IS VO FÁZE BUDOVANIA HW A SW PLATFORMY Dohľad nad dodávkou HW a SW Dohľad nad inštalovaním HW a SW Dohľad nad nastavovaním bezpečnostných parametrov OS, DB, aplikácií, sieťového prostredia Dohľad nad vytváraním používateľov a ich prístupových práv Dohľad nad fyzickou a objektovou bezpečnosťou BEZPEČNOSŤ IS VO FÁZE INTEGRÁCIE A TESTOVANIA IS Realizácia bezpečnostných testov zahrnutých do integračného testovania Dohľad nad konfiguráciou systému BEZPEČNOSŤ IS VO FÁZE AKCEPTAČNÉHO TESTOVANIA Realizácia bezpečnostných testov zahrnutých do akceptačného testovania Dohľad nad zaškolením používateľov Dohľad nad protokolárnym prevzatím IS do rutinnej prevádzky BEZPEČNOSŤ IS VO FÁZE PREVÁDZKY A ÚDRŽBY Manažment konfigurácií a zmien Kapacitný manažment Prevádzková dokumentácia Údržba Monitorovanie bezpečnostne relevantných zmien Auditné záznamy a protokolovanie Bezpečnostné testovanie Riadenie médií Oddelenie povinností Správne používanie softvéru Riadenie zmien softvéru Archivácia a zálohovanie dát Ošetrovanie bezpečnostných incidentov Interný audit bezpečnosti IS Externý audit bezpečnosti IS Bezpečnosť pri likvidácii IS VÝSTUPNÉ DOKUMENTY Z RIADENIA BEZPEČNOSTI IS VO FÁZACH ŽIVOTNÉHO CYKLU IS BUDOVANIE ISMS - SYSTÉMU RIADENIA INFORMAČNEJ BEZPEČNOSTI VZŤAH MEDZI ISMS A BEZPEČNOSŤOU IS PROCESNÝ PRÍSTUP A PDCA MODEL FÁZY BUDOVANIA ISMS Analýza stavu ISMS Určenie rámca ISMS Aktualizácia a dopracovanie dokumentácie ISMS Implementovanie procesov ISMS do praxe Predcertifikačný audit ISMS Certifikačný audit ISMS Udržiavanie a zlepšovanie ISMS DOKUMENTÁCIA ISMS A JEJ RIADENIE Dokumentácia ISMS Záznamy Riadenie dokumentov ZÁVER

10 Používané skratky ANSI AR BIA BM BMIS BMIT BS BSI CASE CC CEN CISS CRAMM CSI DSA FIPS HW IEEE IRCA IS ISMS IT I&A IDEA ITSEC JTC1 MAA MIS NIST OÚ PGP PIN PO PVPO RKP RSA SA/SD SSADM SW TCP American National Standards Institution Analýza rizík Business Impact Analysis analýza obchodných dopadov havárie na spoločnosť Bezpečnostný manažér Bezpečnostný manažér informačného systému Bezpečnostný manažér IT Britský štandard British Standards Institution Computer Aided Software Engineering Common Criteria European Committee for Standardisation Comprehensive Integrated Security System CCTA Risk Analysis and Management Method Computer Security Institute Digital Signature Algorithm Federal Information Processing Standard Hardvér Institute of Electrical and Electronic Engineering International Register of Certified Auditors Informačný systém Information Security Management System - Systém riadenia informačnej bezpečnosti Informačná technológia Identification and Autentication International Data Encryption Standard IT Security Evaluation Criteria Joint Technical Commitee One ( ISO/IEC) Metóda anketnej analýzy Manžérsky informačný systém National Institute of Standards and Technology Osobné údaje Pretty Good Privacy Personal Identification Number Plánovanie obnovy Prípravný výbor pre plánovanie obnovy Riadiaca komisia projektu Rivest, Shamir, Adleman Structured Analysis / Structured Design Structured Systems Analysis and Design Methodology Softvér Transmission Control Protocol 10

11 Vysvetlenie vybraných pojmov Poznámka: Tento terminologický slovník bol vytvorený s využitím týchto zdrojov: 1. ISO/IEC TR 13335, Časť ISO TR ISO COBIT 3 rd edition 5. ISO/IEC STN ISO/IEC 17799: STN ISO/IEC 27001: STN ISO/IEC 90003: Veľký slovník cudzích slov, SAMO, Základné pojmy a normy bezpečnosti informačného systému, REI, s.r.o., 2004 Analýza rizík systematické použitie informácií s cieľom identifikovať zdroje rizika a odhadnúť jeho závažnosť. Akceptácia rizika rozhodnutie prijať určité riziko. Aktívum čokoľvek, čo má pre organizáciu hodnotu. Auditovateľnosť vlastnosť, ktorá zabezpečí, že činnosť subjektu môže byť jednoznačne identifikovateľná pre daný subjekt. Autenticita požiadavka na zaistenie spracovania údajov, ktoré zodpovedajú skutočnosti, teda nie sú sfalšované. Autorizovaná osoba v rámci spoločnosti funkcia/osoba, ktorá je oprávnená vykonávať určitú činnosť alebo má nejaké privilegované oprávnenia, ktorej meno, podpis a osobné údaje sú známe útvaru bezpečnostného manažéra. Bezpečnostný incident ľubovoľná udalosť, ktorá spôsobila alebo by mohla spôsobiť stratu alebo zničenie aktív spoločnosti alebo činnosť, ktorá je v rozpore s platnou bezpečnostnou politikou a bezpečnostnými predpismi. Bezpečnostný manažér IT funkcia/osoba vrcholovo zodpovedná za bezpečnosť IT v rámci celej spoločnosti. Bezpečnostné opatrenia prax, postupy alebo mechanizmy, ktoré znižujú bezpečnostné riziká. V praxi sa taktiež používa ekvivalentný pojem ochranné opatrenia. Bezpečnostná politika súbor základných cieľov, zásad a povinností slúžiacich na zaistenie bezpečnosti. Druh bezpečnostnej dokumentácie vypracovávanej za spoločnosť ako celok, pre jednotlivé IS. Bezpečnostné štandardy rozpracovanie zásad bezpečnostnej politiky pre jednotlivé oblasti a úrovne ochrany IS na úrovni dispozície využívanej pri výkonnej činnosti. 11

12 Bezpečnostný zámer Druh bezpečnostnej dokumentácie vypracovávanej pre IS. Bezpečnostný zámer býva súčasťou bezpečnostného projektu IS. Bezpečnostný projekt Druh bezpečnostnej dokumentácie vypracovávanej pre IS. Platná legislatíva definuje svoje požiadavky na obsah tohto druhu bezpečnostného dokumentu. Bezpečnosť vlastnosť objektu alebo subjektu, ktorá určuje mieru jeho ochrany proti možným škodám. Taktiež stav, pri ktorom je riziko poškodenia osôb alebo vecí obmedzené na prijateľnú úroveň. Ciele bezpečnosti spoločnosť zvyčajne definuje viac cieľov. Medzi hlavné ciele v oblasti bezpečnosti IT patrí zabezpečenie integrity, autenticity, dôvernosti, dostupnosti dát a informačných služieb. Cieľ riadenia IT formulácia požadovaného výsledku alebo zámeru, ktorý má byť dosiahnutý implementovaním riadiacich procedúr v určitej čiastkovej aktivite v rámci IT. Činnosť množina súvisiacich úloh. Dostupnosť schopnosť byť dostupný a použiteľný na požiadanie autorizovanej entity. Dôvernosť vlastnosť, na základe ktorej informácie nie sú sprístupňované a odhaľované neautorizovaným osobám, entitám alebo procesom. Funkcia pre potreby plánovania obnovy činnosti po havárii ide o činnosť vykonávanú niektorým útvarom spoločnosti. Taktiež sa takto označuje pracovné zaradenie zamestnanca alebo miesto v organizačnej štruktúre spoločnosti. S tým súvisí ešte iný pojem a to rola. Funkčnosť riadenia charakteristika systému riadenia, ktorá znamená, že systém riadenia je vybudovaný a že funguje. Gestor aplikácie organizačná jednotka, útvar alebo osoba, ktorá protokolárne preberá do používania vytvorené a/alebo dodané aplikačné programové vybavenie. Gestor zodpovedá tak za funkčnú, ako aj bezpečnostnú stránku aplikácií, ktoré má pod svojou gesciou. Gestor dát organizačná jednotka, útvar alebo osoba, ktorá protokolárne prevzala zodpovednosť za správnosť údajov, s ktorými daný systém nakladá. Hrozba možná príčina neželaného incidentu, ktorý môže vyústiť do poškodenia systému alebo organizácie. Chyba nesplnenie požiadavky na zamýšľané použitie, vrátane požiadavky, ktorá sa týka bezpečnosti. Implementácia bezpečnosti IT praktická realizácia schváleného súboru organizačných, technických, softvérových a iných bezpečnostných opatrení. Incident informačnej bezpečnosti incident informačnej bezpečnosti je signalizovaný jednou alebo viacerými neželanými a neočakávanými udalosťami informačnej bezpečnosti, pri ktorých je vysoká pravdepodobnosť kompromitácie obchodných aktivít spoločnosti a ohrozenia informačnej bezpečnosti. 12

13 Informácia - hovorovo akákoľvek správa získaná rozhovorom, z novín, televízie, rádia. Podľa vedeckej teórie je informácia istá veličina, ktorá znižuje doterajšiu neurčitosť, neznalosť o nejakom jave. Informácie podnikateľské sú informácie obiehajúce v podnikateľskej sfére. Využívajú sa na ovplyvňovanie výrobných, obchodných, riadiacich a iných procesov. Týkajú sa vzťahov ľudí k podnikateľským procesom, vzťahov medzi ľuďmi, potrieb, záujmov a cieľov podniku. Obvyklými druhmi informácií vyskytujúcimi sa v podnikaní sú: informácie z odboru podnikania; informácie právne; informácie ekonomické; informácie o trhu; informácie zo zahraničia; informácie všeobecné; informácie obchodné; informácie organizačné; informácie personálne; informácie o systéme riadenia. Informačná bezpečnosť zachovanie dôvernosti, integrity a dostupnosti informácií, okrem toho aj iné požiadavky, ktoré môžu byť tiež zahrnuté, ako sú autenticita, sledovateľnosť, nemožnosti poprieť zodpovednosť a spoľahlivosť. Informačný systém súbor technických (hardvér) a programových (softvér) prostriedkov, záznamových médií, dát a personálu, ktoré spoločnosť používa na spracovanie informácií v určitej oblasti pôsobenia. Podľa ISO/IEC Information Technology Life Cycle Process je IS definovaný ako integrované zloženie ľudí, produktov a procesov, ktorí poskytujú schopnosti zabezpečiť určené potreby alebo ciele. Inovačný zámer uvážené rozhodnutie (úmysel, plán, cieľ) dosiahnuť obnovenie, zavedenie niečoho nového. Integrita vlastnosť zabezpečujúca presnosť a kompletnosť aktív. Informačná technológia vedecká, technologická a inžinierska disciplína na riadenie techník používaných na spracovanie dát. Taktiež rôzne technológie poskytujúce rôzne služby súvisiace s automatizovanými systémami spracovávania dát, avšak mimo priameho spracovávania dát, napr. telekomunikačný systém, satelitný prenosový systém, , a pod. Individuálna zodpovednosť vlastnosť zaisťujúca, že činnosti určitej entity môžu byť sledované jedinečne pre túto entitu. ISMS Information Security Management Systém Systém riadenia informačnej bezpečnosti je časť celkového systému riadenia podniku, založená na prístupe k rizikám podniku, ktorej úlohou je zaviesť, implementovať, prevádzkovať, monitorovať, revidovať, udržiavať a zlepšovať informačnú bezpečnosť. 13

14 Komerčný produkt na sklade (COTS- Commercial Off The - shelf) softvérový produkt ponúkaný na predaj a na používanie bez nutnosti vykonávať vývojové činnosti. Kompatibilita schopnosť objektov spĺňať pri spoločnom použití za špecifikovaných podmienok príslušné požiadavky (zlúčiteľnosť). Komplexný systém riadenia bezpečnosti systém riadenia podporujúci analýzu, budovanie, riadenie, monitorovanie a vyhodnocovanie bezpečnostných opatrení v celom životnom cykle IS a na všetkých úrovniach budovania IS spoločnosti a na všetkých úrovniach riadenia spoločnosti. Kontaktná osoba osoba určená vedúcim pracovníkom na sprostredkovanie potrebnej podpory alebo na riešenie zadanej úlohy. Kontinuita nepretržitá dostupnosť všetkých zdrojov potrebných pre prevádzku spoločnosti alebo procesov spoločnosti na úrovni prijateľnej pre vedenie. Kontrola činnosti ako sú meranie, skúšanie, testovanie, porovnávanie s kritériom v rozsahu jedného alebo niekoľkých znakov objektu, porovnávanie výsledkov so špecifikovanými požiadavkami s cieľom určiť dosiahnutie zhody v jednotlivých znakoch. Kritická kombinácia prístupových práv kombinácia, ktorá predstavuje zvýšené riziko zneužitia IS, umožňujúca u jedného zamestnanca zlúčenie nežiaducich činností. Kvalita celkový súhrn znakov objektu, ktorými objekt nadobúda schopnosť uspokojovať určené a predpokladané potreby. Manažment systém a metódy riadenia podnikovej činnosti, hospodárstva. Skupina pracovníkov zaoberajúca sa vedením a riadením. Synonymum pojmu riadenie. Manažment kvality všetky činnosti celkovej funkcie manažmentu určujúcej politiku kvality, ciele a zodpovednosť, ktoré sa uplatňujú v systéme kvality prostredníctvom plánovania kvality, operatívneho riadenia kvality, zabezpečenia kvality a zlepšovania kvality. Manažment rizík celkový proces identifikovania, kontrolovania a eliminovania alebo minimalizovania nepredvídaných udalostí, ktoré môžu ovplyvniť zdroje systému. Merať vykonávať meranie Miera premenná, ktorej sa priradí hodnota ako výsledok merania. Metodológia životného cyklu IS metodológia obsahuje štandardy a procedúry, ktoré majú vplyv na plánovanie, analýzu, návrh, vývoj, implementáciu, prevádzku a podporu IS. Metodológie životného cyklu využívané v praxi sú rôzne, napr. waterfall (vodopád), spiral (špirála), inkrementálna, evolutionary (vývojová), fast-track a pod. Model Zmenšené detailné znázornenie predmetu slúžiace obyčajne ako plán alebo vzor. Schéma javu, predmetu, slúžiaca na jeho skúmanie. 14

15 Model budovaného IS umožňuje vymedziť spôsob spracúvania informácií, ktorý bude vyhovovať požiadavkám kladeným na budovaný IS. Model IS by mal špecifikovať najmä nasledovné informácie: rozhranie IS s okolím; funkčnú špecifikáciu; dátovú špecifikáciu; špecifikáciu používateľských rozhraní (interfejsov); Model životného cyklu rámec obsahujúci procesy, činnosti a úlohy týkajúce sa vývoja, prevádzky a udržiavania softvérového produktu, ktoré pokrývajú životnosť systému od definície požiadaviek až po ukončenie jeho používania. Návod opis, ktorý hovorí o tom, čo by sa malo robiť a akým spôsobom, aby sa naplnili ciele vytýčené v jednotlivých politikách Nezhoda nesplnenie špecifikovanej požiadavky. Objekt konfigurácie časť konfigurácie, ktorá spĺňa funkciu konečného používania a ktorú možno v danom referenčnom bode jednoznačne identifikovať. Objektívny dôkaz informácia, ktorej pravdivosť možno preukázať na základe faktov zistených porovnávaním, meraním, skúšaním alebo inými prostriedkami. Ohodnotenie rizík proces porovnania odhadovaného rizika podľa daných kritérií rizika, s cieľom určiť významnosť rizika. Opatrenie prostriedok riadenia rizika, vrátane politík, procedúr, smerníc, praktík alebo organizačných štruktúr, ktoré môžu mať administratívny, technický, riadiaci alebo právny charakter Ošetrenie rizika proces výberu a implementácie opatrení na modifikovanie rizika. Overovanie, verifikácia potvrdenie skúmaním a poskytnutím objektívneho dôkazu, že sa splnili špecifikované požiadavky. Plán akceptačného testovania IS špecifikuje testy, ktoré budú vykonané zo strany zadávateľa IS pred prevzatím IS od zhotoviteľa ešte pred začatím rutinnej prevádzky. Plán by mal definovať testovacie dáta, testovacie procedúry, kritéria pre jednotlivé testy, ako aj zloženie testovacích tímov. Plán kvality dokument opisujúci špecifické postupy v oblasti kvality, zdroje a postupnosti činností, ktoré sa vzťahujú na určitý výrobok, projekt alebo zmluvu. Politika celkový zámer a smerovanie vyjadrené manažmentom formálnou formou Postup špecifikovaný spôsob vykonávania určitej činnosti. Používateľ organizačná jednotka alebo útvar spoločnosti, ktorý využíva informácie získané z IS alebo tieto informácie žiada v rámci služieb poskytovaných systémom, ako aj každý zamestnanec, ktorý používa výpočtovú techniku pri svojej práci. 15

16 Používateľ zodpovedá za bezpečnosť svojho počítačového pracoviska, vedie predpísanú prevádzkovú dokumentáciu počítačového pracoviska a prevádzkuje svoje lokálne aplikácie vrátane zálohovania dát. Preskúmavanie rizík celkový proces analýzy rizík a ich ohodnotenia. Privilegované a špeciálne oprávnenia oprávnenia používateľov IS umožňujúce prácu na úrovni operačného systému alebo nastavenie systémových parametrov operačného systému, databázy alebo aplikácie. Proces sústava vzájomne súvisiacich zdrojov a činností, ktoré transformujú vstupy na výstupy. Procedúra činnosť vykonávaná ľuďmi, spravidla usmernená internou normou riadenia. Synonymum je postup. Programové prostriedky operačné systémy, komerčné programy, vlastné programy a ich zdrojové kódy. Projektant bezpečnosti IS člen riešiteľského tímu dodávateľa IS, ktorý rieši bezpečnostnú stránku IS. Jeho partnerom zo strany budúceho prevádzkovateľa budovaného IS je bezpečnostný manažér IS. Referenčná základňa oficiálne odsúhlasená verzia objektu konfigurácie bez ohľadu na nosič informácií, oficiálne potvrdená a určená v danom čase v priebehu životného cyklu konfigurácie objektu. Replika kopírovanie softvérového produktu z jedného pamäťového média na druhé. Riadenie sústava zásad, nástrojov, prostriedkov (i osôb) usmerňujúcich istú činnosť. Riadenie rizík koordinované aktivity na usmerňovanie a riadenie organizácie vzhľadom na riziko. POZNÁMKA. Riadenie rizík zvyčajne zahŕňa preskúmavanie rizík, ošetrenie rizík, akceptáciu rizika a oznamovanie rizika. Riziko kombinácia pravdepodobnosti nastania udalosti a jej možného následku. Softvérová položka identifikovateľná časť softvérového produktu. Softvérový produkt súbor počítačových programov, postupov a prípadne aj súvisiacej dokumentácie a údajov. Spoľahlivosť schopnosť systému dlhodobo dodržať predpísané vlastnosti pri prevádzke. Taktiež súhrnný termín používaný na opis pohotovosti a činiteľov, ktoré ovplyvňujú spoľahlivosť a to: bezporuchovosť, udržiavateľnosť, zabezpečenosť údržby. Spoločenské požiadavky požiadavky vyplývajúce zo zákonov, vyhlášok, predpisov, kódexov, stanov a iných okolností. 16

17 Správca aplikačnej úlohy/aplikácie zamestnanec spoločnosti autorizovaný na zadávanie požiadaviek na funkčné a bezpečnostné vlastnosti aplikácie. Spolupracuje pri testovaní vyvinutých aplikácií a je oprávnený predpísaným postupom zadávať požiadavky na úpravy softvéru aplikácie. V praxi sa taktiež používa pojem gestor aplikácie. Správca technických prostriedkov správca vykonávajúci spravidla nasledovné činnosti: spracovanie návrhov koncepčného riešenia technického rozvoja IS; identifikácia technických porúch a zabezpečenie ich odstránenia; koordinácia činnosti interných a externých dodávateľov servisných prác; zabezpečovanie dokumentácie technických prostriedkov; zabezpečenie prevádzky EPS, EZS a energetických zdrojov; zabezpečenie prepäťovej ochrany. Systém účelný spôsob usporiadania nejakého celku, sústava. Súbor prvkov spätých istými (vymedzenými) vzťahmi, sústava. Systém kvality organizačná štruktúra, postupy, procesy a zdroje potrebné na uplatnenie manažmentu kvality. Systém riadenia informačnej bezpečnosti ISMS časť celkového systému riadenia, založená na prístupe k riziku organizácie, ktorej úlohou je zriadiť, implementovať, prevádzkovať, monitorovať, preskúmavať, udržiavať a zlepšovať informačnú bezpečnosť. Stratégia základný prístup k riešeniu určitej oblasti. Stratégia bezpečnosti presnejšie povedané, stratégia riadenia bezpečnosti je vlastne základný prístup k otázkam bezpečnosti v rámci spoločnosti. Stupeň naliehavosti obnovy Výsledok analýzy obchodných dopadov spočívajúci v určení priority z hľadiska naliehavosti obnovy danej funkcie, počas obnovovania činnosti spoločnosti po havárii. Podľa stupňa naliehavosti obnovy sa funkcie delia na životne dôležité, dôležité, pomocné a podporné. Špecifikácia dokument špecifikujúci požiadavky. Špecifikácia dátová opis štruktúry a vzájomných vzťahov medzi spracúvanými dátami. Špecifikácia funkčná opis funkcií a ich väzieb, ktoré má IS vykonávať. Špecifikácia požiadaviek na IS opis požiadaviek zadávateľa (budúcich používateľov IS) na systém, ktorý sa má vybudovať. Požiadavky sa zvyčajne členia na funkčné, spoľahlivostné, bezpečnostné a kvalitatívne. Štúdia IS Feasibility Study štúdia vykonateľnosti IS. Druh dokumentu o IS, ktorý sa má vybudovať. Rozpracováva viaceré varianty možného riešenia IS, pre ktorý boli špecifikované základné požiadavky a zámery v Inovačnom zámere IS. Štúdia obsahuje aj ekonomické porovnanie navrhovaných variantov. 17

18 Technické prostriedky počítače, monitory, terminály, skenery, tlačiarne, dátové nosiče, štruktúrovaná kabeláž, a pod. Tretia strana osoba alebo orgán uznané ako nezávislé od strán zainteresovaných pri riešení daného problému. Udalosť informačnej bezpečnosti udalosť informačnej bezpečnosti je identifikovaná výskytom stavu systému, služby alebo siete, ktorý signalizuje možnosť porušenia politiky informačnej bezpečnosti alebo zlyhanie opatrení alebo doposiaľ nezaznamenanú situáciu, ktorá môže byť relevantná z hľadiska bezpečnosti. Uvoľnenie určitá verzia objektu konfigurácie, ktorá je dostupná na daný cieľ ( napríklad uvoľnenie po skúške). Vyhlásenie o aplikovateľnosti dokumentované vyhlásenie opisujúce ciele riadenia a opatrenia, ktoré sú relevantné a platné pre ISMS organizácie Vývoj proces životného cyklu softvéru zahŕňajúci analýzy požiadaviek, návrhu, programovania, integrácie, testovania, inštalácie a podporu akceptácie softvérových produktov. Zabezpečenie kvality všetky plánované a systematické činnosti využívané v systéme kvality a preukazované podľa potreby, s cieľom získať dôveru, že objekt bude spĺňať požiadavky na kvalitu. Zákazník príjemca výrobku dodávaného dodávateľom. Zariadenia na spracúvanie informácií akýkoľvek systém, služba alebo infraštruktúra spracúvania informácií, vrátane fyzických priestorov, v ktorých sa tieto prostriedky nachádzajú. Zhoda splnenie špecifikovaných požiadaviek. Životný cyklu IS informačný systém je dynamický, vyvíjajúci sa celok, ktorý počas svojho vývoja prechádza určitými fázami, ktoré možno považovať za obsahovo relatívne samostatné časti životného cyklu. Súhrn týchto fáz sa nazýva životný cyklus informačného systému. Zraniteľnosť slabina aktíva alebo skupiny aktív, ktorá môže byť zneužitá hrozbami. Zostatkové riziko riziko zostávajúce po ošetrení rizík. 18

19 Prehľad použitej literatúry 1. Projektovanie systémov IT a vývoj SW, metodický materiál REI, s.r.o. Bratislava, O. Oskarson, R.L.Glass: An ISO 9000 Approach to Building Quality Software, D. Lince, H. Sharp, M. Woodman: Introduction to Software Project Management and Quality Assurance, ISO/IEC 12207, Information Technology Life Cycle Procesess 5. Zásady transformácie globálnej bezpečnostnej politiky IT a auditov technologických projektov, metodický materiál REI, s.r.o. Bratislava, Príručka audítora bezpečnosti IS, ISACF - COBIT, E. Yordon: Modern Structured Asnalysis, Yordon Press, As. Uworth, C. Goodland, M. : SSADM A Practice Approach, MC Graw Hill, Rumbaugh and team.: Object- Oriented Modeling and Design, Prentice-Hall, STN ISO/IEC 17799: 2005 : Informačné technológie: Kódex praxe manažérstva informačnej bezpečnosti 11. ISO/IEC 27001: 2005: Systémy riadenia informačnej bezpečnosti Špecifikácia s radami na použitie 12. I. Vrána, K. Richta: Zásady a postupy zavádění podnikových informačních systémů, Grada, STN ISO/IEC TR : Informačné technológie: Návod na manažérstvo bezpečnosti IT, Časť 1: Koncepcie a modely bezpečnosti IT 14. STN ISO/IEC TR : Informačné technológie: Návod na manažérstvo bezpečnosti IT, Časť 2: Riadenie a plánovanie bezpečnosti IT 15. STN ISO/IEC TR : Informačné technológie: Návod na manažérstvo bezpečnosti IT, Časť 3: Techniky pre manažment bezpečnosti IT 16. STN ISO/IEC TR : Informačné technológie: Návod na manažérstvo bezpečnosti IT, Časť 4: Výber bezpečnostných opatrení. 17. Zákon č. 215/2002 Z.z. o elektronickom podpise 18. Zákon č. 215/2004 Z.z. o ochrane utajovaných skutočností 19. Zákon č. 428/2002 Z.z. o ochrane osobných údajov 19

20 20. Vyhláška NBÚ č. 541/2002 Z.z. o obsahu a rozsahu prevádzkovej dokumentácie vedenej certifikačnou autoritou a o bezpečnostných pravidlách a pravidlách na výkon certifikačných činností 20

21 1 Úvod Predmet bol pripravený pre inžinierske štúdium na FIIT v Bratislave, ako predmet nadväzujúci na predmet Manažment bezpečnosti IT zaradený do študijného programu pre bakalárske štúdium. Cieľ predmetu: Vytvoriť u absolventov fakulty vedomostné zázemie pre zvládanie manažmentu procesov prípravy, budovania a prevádzky aj rozsiahlych IS vo veľkých subjektoch a súčasne vytvoriť zázemie pre riešenie bezpečnosti IS, ako integrálnej súčasti všetkých fáz životného cyklu IS. V porovnaní s predmetom zaradeným do študijného programu bakalárov tento predmet prináša navyše najmä: opis fáz životného cyklu IS vrátane dokumentácie vznikajúcej v jednotlivých fázach; opis postupu podniku pripravujúceho a realizujúceho projekt zameraný na vybudovanie nového IS; detailnejší opis procesu analýzy rizík IS; detailnejší opis procesu výberu bezpečnostných opatrení pre IS; detailnejší opis procesu tvorby havarijných plánov a plánov obnovy činnosti IS; detailnejší opis procesu interného a externého auditu bezpečnosti IS; opis zabezpečovania kvality IS vo fázach životného cyklu IS; ako aj informácie týkajúce sa budovania ISMS. Vysvetľovanie problematiky riešenia bezpečnosti IS okrem iného komplikuje skutočnosť, že v praxi môže dôjsť k rôznym postupom pri zabezpečovaní nového IS podniku. Podnik sa napríklad môže rozhodnúť, že celý nový IS, teda tak HW, ako aj SW platformu si zabezpečí sám. Taktiež sa môže rozhodnúť, že nový IS objednáva od vybraného dodávateľa a súčasne, že použije typové riešenie IS. Taktiež sa môže rozhodnúť, že niektoré časti napr. HW platformu IS si vybuduje sám alebo tým poverí niekoho iného, mimo systémového integrátora, ktorý bude dodávať SW riešenie nového IS. Je zrejmé, že variantov, ktoré môžu nastať je viac. V súvislosti cieľom poskytnúť spolu s vysvetľovaním riešenia bezpečnosti IS počas fáz životného cyklu aj obraz o základnom postupe pri budovaní nového IS za rôznych podmienok, sú skriptá napísané tak, že: kapitola 4 vysvetľuje postup podniku budujúceho nový IS s využitím externého dodávateľa, pričom sa využije typové riešenie IS; kapitola 5 až 12 vysvetľuje postup podniku, ak sa rozhodne vybudovať nový IS bez využitia typového riešenia a súčasne niektoré činnosti si bude zabezpečovať podnik sám. 21

22 Východiskom pre spracovanie skrípt, okrem medzinárodných štandardov a uvádzanej literatúry, boli najmä praktické, viac ako 20 ročné skúsenosti autora z prípravy, budovania a prevádzky IS, vrátane riadenia IS vo všetkých fázach životného cyklu, ako aj riešenia bezpečnosti IS. Poznámka: V texte skrípt sú okrem iných pojmov používané viaceré pojmy pre označovanie tej istej veci, napríklad: manažment a riadenie, podnik, organizácia a spoločnosť, procedúra a postup, alebo bezpečnosť IT a informačná bezpečnosť, či fáza a etapa. Je potrebné ich považovať za synonymum. Tieto rôzne pojmy sa používajú v praxi a absolventi by ich mali poznať. 22

23 2 Manažment a informačné procesy 2.1 Informácia Z dostupnej literatúry je možné získať veľké množstvo definícií pojmu informácia. Pre potreby predmetu autor skrípt vytvoril účelovú definíciu: Informácia - je hovorovo akákoľvek správa získaná rozhovorom, z novín, televízie, rádia. Podľa vedeckej teórie je informácia istá veličina, ktorá znižuje doterajšiu neurčitosť, neznalosť o nejakom jave. Informácie podnikateľské sú informácie obiehajúce v podnikateľskej sfére. Využívajú sa na ovplyvňovanie výrobných, obchodných, riadiacich a iných procesov. Týkajú sa vzťahov ľudí k podnikateľským procesom, vzťahov medzi ľuďmi, potrieb, záujmov a cieľov podniku. Obvyklými druhmi informácií vyskytujúcimi sa v podnikaní sú: informácie z odboru podnikania, informácie právne, informácie ekonomické, informácie o trhu, informácie zo zahraničia, informácie všeobecné, informácie obchodné, informácie organizačné, informácie personálne, informácie o systéme riadenia. 2.2 Informačné procesy Bez hlbšieho skúmania je možné tvrdiť, že názvov kapitoly zrejme naznačuje, že pôjde o nejaké procesy súvisiace s informáciami. Ak sa vezme do úvahy súvislosť s témou skrípt, potom je zrejmé, že ide o procesy získavania a spracúvania informácií pre potreby manažmentu procesu prípravy, návrhu, budovania a prevádzky IS, vrátane riešenia jeho bezpečnosti. Podrobnejšie členenie procesu získavania a spracúvania informácií pre potreby riadenia procesu prípravy, návrhu, budovania a prevádzky IS, vrátane riešenia jeho bezpečnosti je nasledovné: získavanie informácií, posudzovanie informácií, vyhodnocovanie informácií, spracúvanie informácií, vytváranie informácií, používanie informácií, 23

24 poskytovanie informácií. Uvádzané druhy informačných procesov môžu byť súčasne aj druhmi informačných procedúr. Rozdiel spočíva v tom, že v prípade procedúr pôjde o činnosti vykonávané ľuďmi, zatiaľ čo informačné procesy môžu byť vykonávané automatizovane, bez účasti človeka. 2.3 Manažment Pre potreby predmetu autor skrípt vytvoril účelovú definíciu: Manažment systém a metódy riadenia podnikovej činnosti, hospodárstva. Skupina pracovníkov zaoberajúca sa vedením a riadením. Synonymum pojmu riadenie. V súvislosti s témou predmetu je potrebné ešte poznať vymedzenie pojmov: manažment rizík, manažment kvality. Manažment rizík celkový proces identifikovania, kontrolovania a eliminovania alebo minimalizovania nepredvídaných udalostí, ktoré môžu ovplyvniť zdroje systému IT. Manažment kvality všetky činnosti zamerané na určenie politiky kvality, ciele a zodpovednosť, ktoré sa uplatňujú v systéme kvality prostredníctvom plánovania kvality, operatívneho riadenia kvality, zabezpečenia kvality a zlepšovania kvality. 2.4 Informačný systém a informačná technológia Pre potreby predmetu autor skrípt vytvoril účelovú definíciu: Informačný systém súbor technických (hardvér) a programových (softvér) prostriedkov, záznamových médií, dát a personálu, ktoré spoločnosť používa na spracúvanie informácií v určitej oblasti pôsobenia. Medzinárodný štandard ISO/IEC Information Technology Life Cycle Process, vydaný v roku 1995 definuje informačný systém ako integrované zloženie ľudí, produktov a procesov, ktorí poskytujú schopnosti zabezpečiť určené potreby alebo ciele. Informačná technológia vedecká, technologická a inžinierska disciplína na riadenie techník používaných na spracovanie dát. Taktiež rôzne technológie poskytujúce rôzne služby súvisiace s automatizovanými systémami spracovávania dát, avšak mimo priameho spracovávania dát, napr. telekomunikačný systém, satelitný prenosový systém, , a pod. 24

25 3 Životný cyklus IS Informačný systém je dynamický, vyvíjajúci sa celok, ktorý počas svojho vývoja prechádza určitými fázami. Model IS je znázornený obrázkom č Súhrn týchto fáz sa nazýva životný cyklus informačného systému. Vývoj životného cyklu informačného systému napreduje na základe logickej nadväznosti vývojových fáz, ktoré možno považovať za obsahovo relatívne samostatné časti životného cyklu. Tieto fázy je však ťažké striktne ohraničiť, nakoľko niektoré konkrétne činnosti vykonávané počas jednotlivých špecifikovaných fáz môžu tieto fázy presahovať. Na druhej strane, pri vytýčení a pomenovaní fáz životného cyklu sa vždy vychádza z istého uhlu pohľadu, z istých kritérií, na základe ktorých je potrebné životný cyklus rozdeliť. Pri zmene týchto kritérií nasleduje zmena štruktúry (a pomenovania) fáz životného cyklu. Jednotlivé fázy by mali byť rozlíšené určitými špecifickými atribútmi, ktoré ich charakterizujú. Predovšetkým ide o podmienky začatia fázy, potrebné vstupy a spôsob ich overovania, činnosti vykonávané počas fázy, výsledné výstupy a dokumenty a spôsob ich overovania, podmienky ukončenia fázy. Pre pochopenie životného cyklu a jeho fáz, je potrebné definovať, čo je to informačný systém. IS je definovaný ako integrované zloženie ľudí, produktov a procesov, ktorí poskytujú schopnosti zabezpečiť určené potreby alebo ciele. Elementy tvoriace systém sú uvedené na nižšie uvedenom obrázku. Hardvér, softvér, dokumentáciu a ľudí nie je potrebné podrobnejšie opísať. Detailnejšie opíšeme databázu a procedúry. Databáza je veľká, organizovaná skupina informácií sprístupňovaná softvérom, ktorý je integrálnou súčasťou systémových funkcií. Procedúry sú kroky definujúce špecifické použitie systémových elementov alebo procedurálneho kontextu, v ktorom sa systém nachádza. Dôležité je, že komponenty systému, hardvérové a softvérové (operačný systém), nie sú zvyčajne vyrobené špeciálne pre určitý systém. Nikdy sa pri vývoji softvéru IS nesmie zabúdať na nevyhnutnú spätosť medzi hardvérom a softvérom. Aj keď je hardvér a softvér produkovaný samostatne, rozhodujúci vplyv na funkčnosť systému bude mať ich vzájomná spolupráca. 25

26 Dokumentácia Hardvér VSTUP Databáza Firmvér Softvér VÝSTUP Ľudia Obrázok č. 3-1 Model IS Medzinárodný štandard ISO/IEC 12207, Information Technology Life Cycle Process, bol vydaný v roku Tento štandard zavádza základný rámec pre procesy životného cyklu. Obsahuje procedúry, aktivity a úlohy, ktoré sú požadované počas získavania obsahu systému, samostatných softvérových produktov a služieb a počas dodávky, vývoja, prevádzky a údržby softvérových produktov. Metodológia riadenia životného cyklu IS obsahuje štandardy a procedúry, ktoré majú vplyv na plánovanie, analýzu, návrh, vývoj, implementáciu, prevádzku a podporu IS. Metodológie životného cyklu sú rôzne, napr. waterfall (vodopád), spiral (špirála), inkrementálna, evolutionary (vývojová), fast-track. Fast-track metodológie modifikujú niektorú z metodológií tým spôsobom, že dochádza k vynechaniu niektorej fázy. Organizácia môže použiť už existujúcu metodológiu alebo vytvoriť si vlastnú. Životný cyklus môže byť vybraný podľa povahy programu, odboru, metód a nástrojov použitých pre vývoj softvéru, riadenie a vypracovávanie dokumentov. Výber metodológie životného cyklu nie je jednoduchá úloha. Všetky zo známych metodológií majú svoje výhody a obmedzenia, ktoré je potrebné brať do úvahy. Pri návrhu metodológie je potrebné brať do úvahy: typ vytváraného systému; vývojové nástroje (pre programovanie objektovo orientované alebo iné). Vývojové nástroje CASE obsahujú aj čiastočnú alebo úplnú metodológiu pre podporu životného cyklu IS. 26

27 3.1 Fázy životného cyklu IS Ako už bolo uvedené skôr, vývoj životného cyklu informačného systému napreduje na základe logickej nadväznosti vývojových fáz, ktoré možno považovať za obsahovo relatívne samostatné časti životného cyklu. Členenie životného cyklu IS však nie je pri všetkých modeloch rovnaké, čo súvisí najmä s tým, že prístup k životnému cyklu IS je rozdielny. Napríklad: Evolučný model člení životný cyklus na: koncept projektovej realizácie, nové aplikácie a systémy, úlohy prislúchajúce k čiastkovému projektu, nasadenie projektov, analýza IS, vývoj, inštalácia a podpora, hodnotenie používateľa,... Waterfall model člení životný cyklus na: fázu požiadaviek, fázu návrhu, fázu implementácie, fázu testovania, fázu uvoľnenia, post - implementačnú fázu. Špirálový model člení životný cyklus na: plánovanie, analýzu rizík, vývoj, hodnotenie používateľa, atď. Dôležité však je, že konkrétny používateľ si môže podľa svojich potrieb upraviť fázy životného cyklu IS podľa svojich potrieb. 3.2 Modely životného cyklu IS Medzi základné modely životného cyklu IS patria: Waterfall model, viď obrázok č. 3-2 Waterfall model (niekedy označovaný ako Grand Design) bol prvý krát identifikovaný ako formálna alternatíva pre code-and-fix, v roku Waterfall model prvýkrát formalizoval rámec pre vývojové fázy, začiatočné požiadavky, aktivity pri návrhu a produkčnú dokumentáciu počas jednotlivých fáz. Hlavnou nevýhodou tohto modelu je vlastná sekvenčná povaha snaha vrátiť sa späť o dve alebo viac fáz, aby sa vyriešil problém alebo nedostatok (deficiencia), produkuje veľké finančné náklady a plánovanie. Vodopádový model je založený na jednoznačnom vymedzení činností, ktoré na seba nadväzujú a vzájomne sa neprelínajú. Jedná sa o klasický model, z ktorého vychádzajú ďalšie modely. Evolučná metóda / Prototypovanie, viď obrázok č. 3-3 Evolučný životný cyklus je alternatívnou stratégiou pre systémy, kde sa budúce požiadavky postupne spresňujú a technické riziko alebo možnosť okamžitej implementácie je problematická. 27

28 Evolučná stratégia je založená na formovaní vlastností jadra, systémový dizajn má modulárnu štruktúru a aktualizácie sú vytvárané pre upgrady systému alebo pri zmene požiadaviek na systém. Na obrázku je znázornená Pressmanova interpretácia evolučného modelu, kde sa prvá generácia špirály rozvíja do druhej generácie rozšírenej špirály. Metóda evolučného životného cyklu je vhodná pre softvérové systémy, ktoré sú založené na jadre systému, ktoré však nie je špecificky identifikovateľné. Ide hlavne o prípady softvéru pre podporu rozhodovania, ktoré sú interaktívne, s komplexnými rozhraniami stroj-človek. Táto stratégia požaduje vývoj inkrementov softvéru, ktoré demonštrujú používateľovi, čo je obsiahnuté počas celého vývojového procesu, ako je ilustrované na ďalšom obrázku. Evolučná metodológia je používaná pre stredne a veľmi rizikové systémy. Aj keď finálna verzia systému vyžaduje väčšiu námahu na vývoj, nadbytočné úsilie je rozložené do poskytnutia lepšieho produktu, ktorý redukuje prevádzkové a servisné náklady. Inkrementálna metóda Táto metodológia umožňuje používateľovi používať časť produktu a životný cyklus inkrementálnej metodológie je charakterizovaný ako: vytvoriť časť, testovať časť, doručiť iniciálnu funkcionálnu časť z celkovej funkčnosti. Podmnožina je pravidelne upgradovaná, pokiaľ nie sú splnené požiadavky používateľa. Počet, veľkosť a fázovanie inkrementálnych dodávok (buildov) je závislá od definovania úplnosti programu v spolupráci s používateľom. Inkrementálna metodológia je vhodná pre málo a stredne rizikové systémy, kde sú požiadavky používateľa plne definované alebo ohodnocovanie iných hľadísk (riziko, plánovanie, financovanie, veľkosť programu) indikuje fázy približovania sa dostatočne rozumne. Použitie inkrementálnej metódy je vhodné pri komerčných projektoch, ale dôležitým faktorom sú potrebné, plne definované požiadavky používateľa. Špirálový model Špirálová metóda (implementovaná špirálovým modelom), vytvorená Barrym Boehmom, poskytuje prístup redukcie rizika v životnom cykle. Model je založený na kombinácii prototypovania a analýzy rizík. 28

29 Práce na projekte sú organizované tak, aby sa cieľavedomo minimalizovali problémy spojené s klasickým vodopádovým modelom. Jednotlivé kroky sa v špirále opakujú, ale pokiaľ možno na vyššom stupni zvládnutia problematiky. Každá fáza vodopádu je riešená zhodným postupom, ktorý sa skladá z nasledovných dielčich krokov: o určenie predmetu riešenia, alternatív a obmedzení; o vyhodnotenie alternatív, identifikácia a riešenie rizík; o vývoj produktu pre danú úroveň; o plánovanie ďalšej fázy. V- model, viď obrázok č Klasický životný cyklus vodopádový model obsahuje 6 fáz. Pri zmene znázornenia životného cyklu vzniká takzvaný V - model, ktorý zvýrazňuje tri základné časti životného cyklu : o o o dekompozícia a definícia systému; implementácia systému; testovanie systému. V- model určitým spôsobom modifikuje vodopádový model, kde V- model rozoberá požiadavkovú fázu vodopádového modelu na dve fázy, fázu plánovania a fázu analýzy. V podstate všetky modely životného cyklu vychádzajú z vodopádového modelu, pričom dochádza k modifikácii jednotlivých fáz v závislosti od oblasti, kde sa systém realizuje a od zvolenej metodiky realizátora. Autor skrípt pre potrebu predmetu účelovo navrhol a použil vlastný model životného cyklu IS. Jeho členenie na fázy je nasledovné: o o o o o o o o plánovanie a riadenie procesu budovania IS, analýza IS, projektovanie IS, vývoj SW, budovanie HW a SW platformy IS, integrácia a testovanie IS, akceptačné testovanie IS, prevádzka a údržba IS. Tento model životného cyklu IS je znázornený obrázkom č Vybrané fázy takto definovaného životného cyklu IS majú osobitné postavenie a to: plánovanie a riadenie procesu budovania IS, prevádzka a údržba IS. 29

30 Je to dané tým, že: Fáza Plánovania a riadenia procesu budovania IS začína ako prvá, prebieha v pozadí ďalších fáz a končí až odovzdaním IS do rutinnej prevádzky. Fáza prevádzky a údržby IS je časovo najdlhšou fázou, normálne trvajúcou 4 až 8 rokov. IS slúži tomu kto si ho objednal, napĺňa poslanie keď podporuje činnosti útvarov spoločnosti, ktoré využívajú jeho funkčné schopnosti. Obrázok č. 3-2 Waterfall model životného cyklu IS Požiadavková fáza Fáza návrhu Fáza implementácie Fáza testovania Fáza Uvoľnenia Post implementačná fáza 30

31 Obrázok č. 3-3 Evolučný model životného cyklu IS 31

32 Obrázok č. 3-4 V- Model životného cyklu IS Plánovanie informácie o problémoch prevádzky požiadavky na zmeny Prevádzka a údržba systému špecifikácia strategických požiadaviek prevádzkovaný systém Analýza systému špecifikácia akceptačných testov Akceptačné testovanie špecifikácia vytváraného systému integrovaný systém Návrh systému špecifikácia integračných testov Integrácia a testovanie špecifikácia architektúry systému a programových modulov Implementácia systému Implementované moduly 32

33 VÝVOJ SW PLÁNOVANIE A RIADENIE ANALÝZA IS PROJEKTOVANIE IS INTEGRÁCIA A TESTOVANIE IS AKCEPTAČNÉ TESTOVANIE PREVÁDZKA A ÚDRŽBA IS BUDOVANIE HW A ZÁKLADNEHO SW Obrázok č. 3-5 Životný cyklus IS 33

34 4 Budovanie podnikového informačného systému 4.1 Potreba zavedenia nového informačného systému Budovanie IS v súčasnosti stojí nemalé finančné prostriedky, často vyžaduje účasť veľkého počtu špecialistov a to nielen na informačné technológie, ale aj na oblasť podnikania či pôsobnosti, ktorá bude daným IS podporovaná. Vedenie organizácie/podniku/spoločnosti by si malo pred začatím procesu budovania IS zodpovedať niekoľko otázok. Získanie správnych a pravdivých odpovedí na ďalej uvedené otázky nie je v praxi ľahké. Ich zodpovedné zodpovedanie však na druhej strane môže zabrániť prípadným sklamaniam a prípadným finančným stratám. Medzi základné otázky súvisiace s rozhodovaním o budovaní, či nebudovaní nového firemného IS patria tieto: 1. Je nový IS skutočne potrebný? 2. Poznáme a berieme do úvahu riziká spojené s projektom zameraným na vybudovanie nového IS? 3. Vieme vytvoriť primerané podmienky pre prípravu a realizáciu projektu zameraného na vybudovanie nového IS? 4. Budeme IS budovať sami alebo si ho necháme vybudovať externou firmou? Je nový IS skutočne potrebný? Vyhodnotiť skutočnú potrebu najmä nového IS nie je vôbec jednoduché. Vyplýva to z toho, že takáto potreba skrýva v sebe rôzne dôvody pre alebo proti takémuto rozhodnutiu. Pre kvalifikované zodpovedanie takejto globálne postavenej otázky je potrebné poznať odpovede na rad iných otázok ako sú: Potrebujeme zlepšiť zber, distribúciu, spracúvanie a či poskytovanie údajov v spoločnosti? Zvýši nový IS podnikovú kultúru a skvalitní proces spracúvania dát? Potrebujeme vyššiu prevádzkovú kapacitu, spoľahlivosť a či bezpečnosť informácií? Potrebujeme kvalitnejšie podklady pre činnosť podnikových útvarov? Pomôže nový IS odstrániť existujúci neporiadok? Prispeje nový IS k lepšiemu vykazovaniu voči nadriadenému orgánu Zvýši nový IS spokojnosť našich zákazníkov a obchodných partnerov? 34

35 Častými odporcami úvah o vybudovaní nového IS sú argumenty niektorých pracovníkov organizácie ako sú: Starý informačný systém nás stál veľa, je síce nepohodlný, zdĺhavý a aj výstupné zostavy nie sú najlepšie, avšak musíme ho používať ďalej, aby sa nám vrátili do neho vložené prostriedky, Používanie nového IS nám skomplikuje vzťahy so zákazníkmi, bude treba venovať veľa času na nové zladenie sa so subdávateľmi a pod. Poznáme a berieme do úvahu riziká spojené s projektom zameraným na vybudovanie nového IS? Projekt budovania nového IS je vždy doprevádzaný problémami tak všeobecne platnými, ako aj špecifickými pre daný podnik či organizáciu. Nesmie sa taktiež zabúdať aj na určitú mieru rizika neúspechu. Podstatné je však to, že veľa všeobecne známych problémov môže vyriešiť a koniec koncom aj mieru rizika môže znížiť samotná organizácia budujúca nový IS. Skutočne to závisí veľa krát na správne zvolenom postupe, seriózne vykonanej práci a správne zvolených dodávateľoch, ako aj na vytvorení pozitívneho klíma vo vnútri organizácie vo vzťahu k novému IS. Vieme vytvoriť primerané podmienky pre prípravu a realizáciu projektu zameraného na vybudovanie nového IS? Zložkami primeraných podmienok pre prípravu a realizáciu projektu zameraného na vybudovanie nového IS okrem iných sú najmä: podpora vedenia organizácie projektu, organizačné zabezpečenie, dostatočný rozpočet, vytvorenie vnútropodnikovej legislatívy pre prevádzku a využívanie nového IS, kontinuálne informovanie ľudí zapojených do projektu, dobrý motivačný program pre riešiteľov a spolupracujúce útvary. 35

36 4.2 Príprava a realizácia projektu zameraného na vybudovanie IS Základnými zložkami procesu prípravy a realizácie projektu zameraného na vybudovanie IS sú: Zaradenie projektu IS do rozvojového plánu, Posúdenie vykonateľnosti projektu IS, Zaistenie podpory pre projekt IS, Formulovanie rozsahu projektu, Návrh riadenia realizácie projektu, Príprava a realizácia projektu, Implementácia IS, Prevádzka, údržba a rozvoj IS Zaradenie projektu IS do rozvojového plánu Vynaloženie finančných prostriedkov na vybudovanie nového IS zo strany podniku/organizácie má svoje pravidlá. manažérov Určite všeobecne platí, že väčšie finančné objemy súvisiace s novým IS musia byť najprv schválené vlastníkmi v rámci schvaľovania nejakých, napríklad strednodobých či ročných obchodných a/alebo finančných plánov a až potom sú realizované v praxi, pretože vynakladanie peňazí na nákup HW, vývoj SW a ďalšie aktivity by mohlo byť zo strany vlastníkov podniku/organizácie v ďalšom období chápané aj negatívne a to aj ako neoprávnené nakladanie s majetkom vlastníkov. V praxi sa proces budovania nového IS často naštartuje vypracovaním, prerokovaním a schválením Investičného alebo Inovačného zámeru. Po schválení investičného zámeru sa s tým projekt zaradí do rozvojového plánu podniku, ktorý je prerokovaný a schválený príslušnými orgánmi ako sú vedenie podniku, predstavenstvo či dozorná rada. Nezriedkavým javom, najmä keď nový IS bude stáť desiatky či stovky miliónov korún, je schvaľovanie projektu nového IS zaradené do programu valného zhromaždenia akcionárov spoločnosti. Informačná stratégia podniku, súčasťou ktorej môže byť aj budovanie nového IS, nemôže vznikať odtrhnutá od strategického podnikateľského plánu, práve naopak musí z neho vychádzať či podporovať ho. Zámer vybudovať nový IS odtrhnutý od podnikateľského plánu vedie k budovaniu nákladného systému, ktorý nebude schopný podporovať informačné potreby podniku. 36

37 Je vhodné a výhodné keď pri strategickom podnikateľskom pláne sa na aktíva podniku nazerá procesne. Základné podnikateľské procesy je možné rozložiť na množstvo čiastkových procesov so vzájomnými väzbami. Niektoré procesy sú z hľadiska predmetu podnikania podniku kritické, iné len vytvárajú prostredie pre správne fungovanie organizmu podniku. Pre každý proces je možné pritom definovať vstupy a výstupy, vrátane informácií. Zmena informačnej obsluhy niektorých podnikateľských procesov umožňuje lepšiu organizačnú štruktúru príslušných pracovísk. Takéto a podobné okolností by mali byť brané do úvahy pri vytváraní informačnej stratégie organizácie/podniku. Je vhodné, ak zámer budovať nový IS sa podporí vypracovaním, prerokovaním a schválením informačnej stratégie podniku, ktorá sa zameriava na: zmapovanie súčasného stavu informačnej obsluhy podnikových agend a oblastí pôsobenia podniku špecifikovanie budúceho možného stavu informačnej obsluhy podnikových agend a oblastí pôsobenia podniku (vízia) definovanie možných variantov riešenia vo väzbe na priority podniku predpokladané nároky definovaných variantov zhodnotenie nákladov a prínosov jednotlivých variantov. Ideálnym stavom je, keď vybudovanie nového IS súvisí s najvhodnejším variantom informačnej obsluhy podnikových agend a oblastí pôsobenia podniku v ďalšom období Posúdenie vykonateľnosti projektu IS Vykonateľnosť projektu vo všeobecnosti znamená, že sme schopní daný projekt riadiť a doviesť ho do úspešného konca. Vykonateľnosť projektu IS má niekoľko faktorov. Sú to najmä: Ochota vedenia podniku podporovať takýto projekt, Spôsob zorganizovania procesu budovania, Požiadavky na kvalitu vybudovaného IS, Formy komunikácie s IS, Iné hľadiska. Ak uvedené faktory sú v organizácii zabezpečiteľné v plnom rozsahu, potom vykonateľnosť projektu IS je 100 %. Ak ich zabezpečiteľnosť rôzne klesá, potom výsledná vykonateľnosť projektu je nižšia. 37

38 Problém je, keď zistená vykonateľnosť je pod 50 %, pretože pravdepodobnosť úspešného ukončenia projektu sa stáva kritická a je potrebné zvážiť či má zmysel takýto projekt vôbec začínať. Ďalej uvádzame niektoré faktory, ktoré sú všeobecne známe a uznávané ako tie, ktoré môžu mať vysoký význam pre úspech projektu zameraného na vybudovanie nového IS, vrátane komentáru k niektorým z nich. 1. Projekt IS vedú dobre motivovaní vybraní vedúci pracovníci podniku. Dochádza k chybnej predstave, že tým je zabezpečené celkové pochopenie nového IS. Je potrebné rátať tak z výskytom nepochopenia cieľov, ako aj so zámerným odporom niektorých pracovníkov voči novému IS. 2. Nový IS vynucuje urobenie poriadku do oblastí, ktorých sa dotýka. Nový IS si zvyčajne vynucuje doteraz nezaužívaný postup prác, to však ľudia nemajú veľmi radi. Zmeny v postupoch nie sú prijímané ľahko, často si ich treba vynútiť. 3. V podniku ťažia pracovníci s monopolným prístupom k informáciám. Nový IS prináša poriadok v dostupnosti informácií podľa prístupových privilégií prideleným jednotlivým roliam. Tí, ktorí strácajú informačný monopol budú nespokojní. 4. Mnoho ľudí očakáva ideálny IS a ideálneho dodávateľa. Neexistuje ideálny IS ani ideálny dodávateľ. Častým zjavom v praxi je, že budúci používatelia nevedia nadefinovať svoje požiadavky na budúci informačný systém. Častým zjavom v praxi je aj výskyt zlyhania dodávateľa pri zabezpečovaní harmonogramu, ale aj funkčnosti či spoľahlivosti nového IS. Bezpečnosť IS ešte stále predstavuje často zanedbávanú a nepochopenú stránku nového IS. 5. Projekt budovania nového IS musí mať pridelenú vysokú prioritu. Vybudovanie IS nie je prioritou podniku. Prioritou je získať lepší nástroj pre podporu niektorej podnikateľskej aktivity elektronickým spracúvaním dát. Bez nového IS to v ďalšom období už nepôjde tak, ako to firma nevyhnutne potrebuje. 6. Projekt realizujú viacerí zamestnanci. Budovanie nového IS nemôže byť založené len na nadšení, kľúčovou sa stáva správna motivácia všetkých a najmä tých kľúčových osôb. 7. Súčasťou projektu musí byť plánovanie a kontrola. Projekt trvajúci niekoľko mesiacov až rokov sa nezaobíde bez plánovania a dôslednej kontroly. 8. Od začiatku projektu je treba venovať pozornosť HW a SW platforme IS. HW a SW platforma musí byť vyvážená a súčasne nekonfliktná. Má rozhodujúci vplyv na výkonnosť, spoľahlivosť a bezpečnosti nového IS. 9. Vedenie poznať musí poznať odchýlky od plánovaného harmonogramu, ich príčiny a musí byť schopné ich predvídať. Dôležitým prvkom sa stáva zber spätných informácií a presné opisovanie stavu, vrátane existujúcich problémov. 10. Často chýbajú ucelené záväzné interné predpisy pre obeh dokladov a spracúvanie informácií. Chýbajúce interné predpisy je nutné vytvoriť a zaviesť do praxe. Pozor treba dávať aj na vynútené zmeny už existujúcich predpisov. 38

39 11. Často chýbajú skúsenosti so zdieľaním dát a ich paralelným spracúvaním. Viaceré podnikové procesy môžu vyžadovať zdieľaný prístup k dátam. Nesmie sa zabúdať na rozsah oprávnení pri zdieľaní dát a ich paralelnom spracúvaní rôznymi aplikáciami/ útvarmi. 12. Bezpečnosť IS a spracúvania informácií nie je riešená systémovo a od začiatku projektu. Za žiadnych okolnosti by sa nemal pripustiť stav, keď bezpečnosť je riešená až na poslednú chvíľu, či až počas prevádzky IS Zaistenie podpory pre projekt IS Z rôznych výskumov realizovaných v praxi vyplýva, že pre vykonateľnosť projektu má rozhodujúci vplyv ochota vedenia podniku realizovať projekt IS. Ochota vedenia podniku sa člení na: vyhlasovanú, realizovanú v praxi. Je nutné, aby všetci vedeli, že vedenie podporuje takýto projekt, avšak ešte dôležitejšie aby, vedenie podporu projektu realizovalo v praxi najmä: presadením finančného zabezpečenia projektu v rozpočte podniku, prijatím potrebných organizačných opatrení a personálnym zabezpečením, presadením zmien interných noriem, dôslednou kontrolou priebehu realizácie projektu a vyvodzovaním dôsledkov na základe objektívnych dôkazov o existujúcom stave. Nestačí ak projekt podporuje len jednotlivec, projekt musí podporovať celé vedenie podniku. Súčasne musí existovať niekto, kto má sledovanie realizácie projektu predelené do svojich povinností počas celej doby trvania projektu a pravidelne informuje projektovú radu a vedenie podniku Formulovanie rozsahu projektu Nepísaným pravidlom praxe je, že rôzni ľudia a útvary budú mať rôzne očakávania od nového IS. Iné si predstavuje vedenie podniku, iné potenciálni používatelia či technický personál alebo dodávatelia, či zákazníci a partneri. To však má vplyv aj na určenie rozsahu projektu. Aby sa hneď o začiatku predišlo špekuláciám o tom, čo všetko IS nezabezpečuje alebo čo všetko ma navyše voči skutočným potrebám, je potrebné hneď na začiatku definovať rozsah projektu. 39

40 Je vhodné ak rozsah projektu vychádza zo schválenej Informačnej stratégie podniku, ktorá by mala byť pri určovaní rozsahu projektu vodítkom. Rozsah projektu IS musí vyjadriť základný: obsahový, časový, a finančný rámec projektu zameraného na vybudovanie IS a mal by obsahovať najmä: 1. Zoznam oblastí pôsobnosti podniku, ktoré IS bude obsluhovať, 2. Zoznam organizačných jednotiek, pre ktoré budú komponenty IS slúžiť, 3. Prepojenosť komponentov a požadovaný rozsah zdieľania dát, 4. Kategórie používateľov a ich roly, 5. Plánované termíny pre uvedenie komponentov IS do skúšobnej prevádzky a o do rutinnej prevádzky, 6. Plánované finančné prostriedky na projekt Návrh riadenia realizácie projektu Projekt zameraný na vybudovanie nového IS podniku je možné svojim rozsahom a zložitosťou považovať za veľký projekt. Preto takýto projekt sa vyžaduje uplatnenie zásad pre riadenie rozsiahlych projektov. Projekt zameraný na vybudovanie IS môže byť členený na niekoľko fáz. Jedným z možných členení je toto: príprava IS, zavedenie IS, prevádzkovanie IS. Tieto fázy sa od seba líšia tak vykonávanými úlohami, ako aj používanými metódami riadenia. Jedným z cieľov riadenia realizácie projektu je vyhnúť sa možným rizikám, medzi ktoré patria najmä: 1. Nedostatočná podpora vedenia podniku 2. Nedostatočná kvalifikácia, skúsenosti a schopnosti členov tímov a manažérov 3. Zle určené kompetencie 4. Zlá spolupráca členov tímov a tímov medzi sebou 5. Nestabilita tímov 6. Nedostatočné kapacitné zaistenie projektu 7. Nedodržiavanie termínov, kvality a rýchlosti rozhodovania a riešenia problémov 8. Zle zaistenie logistiky projektu 9. Neskoré zaistenie ľudských a technických zdrojov 10. Zlá adresácia realizačných krokov ( termíny, zodpovednosť,..). 40

41 Veľkosť reálneho rizika vždy závisí od spôsobu riadenia konkrétneho projektu. Riziká je možné vhodnými krokmi eliminovať alebo znížiť ich dopad na minimum. Preto správne riadenie realizácie projektu budovania IS tiež vyžaduje : 1. Ustanovenie riadiacej komisie projekt, ktorej členovia majú potrebnú kvalifikáciu, poznatky a skúsenosti často nie sú zahrnutí špecialisti na informačnú bezpečnosť. 2. Formulovanie zásadných princípov projektu. 3. Rozhodnutie o vlastnom vývoji alebo objednávke IS od externého dodávateľa. 4. Venovanie náležitej pozornosti úvodnej fáze projektu, najmä informačnej stratégii a jej analýze. 5. Vytvorenie harmonogramu vývoja a implementácie komponentov IS a modulov v súlade s prioritami podniku. 6. Koordinácia dodávateľov a používateľov. 7. Uplatňovanie organizačných opatrení až do úrovne operatívneho riadenia. 8. Spoľahlivý postup monitorovania postupu prác na projekt, vznikajúcich problémov a mechanizmov nápravných opatrení. 9. Písomné dokumentovanie rokovaní, rozhodnutí, informovanie celého podniku a relevantných druhých a tretích strán Vedenie projektu Projekt zameraný na vybudovanie IS vyžaduje riadenie dvoma smermi a to: koncepčne operatívne. Týmto požiadavkám je potrebné prispôsobiť štruktúru riadiacich orgánov projektu a právomoci ich členov. Príklad všeobecne platnej štruktúry riadiacich orgánov projektu IS je uvedený obrázkom č Obrázok č. 4-1 Štruktúra riadiacich orgánov projektu IS 41

42 Priebeh vzniku riadiacich orgánov projektu možno opísať nasledovne: 1. Vedenie podniku menuje Riadiacu komisiu projektu RKP, ktorá vrcholovo riadi projekt. RKP zodpovedá vedeniu organizácie/podniku za celý projekt tak po stránke obsahovej, termínovej, ako aj finančnej. Dôležité je vyváženie komisie vhodným včlenením tak manažérov, ako aj IT špecialistov, aby komisia mala potrebné kvalifikáciu, skúsenosť a schopnosti. Dôležité sú aj jej kompetencie pre celkové riadenie projektu. Jedným z možných jednoduchého zloženia RKP je: vedúci projektu (predstaviteľ podniku) zástupca vedúceho projektu (predstaviteľ hlavného dodávateľa) metodik projektu špecialisti. Vedúci projektu zvyčajne zodpovedá za koncepčné riadenie a zástupca vedúceho projektu zodpovedá za operatívne riadenie projektu. Počet špecialistov sa pohybuje od 3 do 5 a viac, vrátane bezpečnostných špecialistov. Ich profesijné zloženie závisí najmä od HW a SW platformy OS. Podľa názoru autora skrípt z množstva špecialistov zaradených to RKP je potrebné samostatne definovať, obsadiť a využívať 2 funkcie/roly a to: bezpečnostný manažér IS bezpečnostný projektant IS. Bezpečnostný manažér IS je zástupca na strane podniku, ktorý zodpovedá za riešenie bezpečnosti IS. Takže v spolupráci s inými odborníkmi špecifikuje požiadavky, posudzuje predkladané bezpečnostné riešenia zo strany dodávateľa IS a dohľaduje realizáciu schváleného variantu riešenia bezpečnosti IS. Bezpečnostný projektant IS je zástupca na strane dodávateľa IS, ktorý zodpovedá za riešenie bezpečnosti IS, navrhuje bezpečnostné riešenie IS na strane dodávateľa a realizuje schválený variant bezpečnostného riešenia v budovanom IS. 2. Celý projekt sa spravidla skladá z niekoľkých čiastkových projektov, napríklad projektov jednotlivých komponentov IS. Zvládnutie čiastkových projektov vyžaduje odlišné špecializované znalosti, napríklad účtovanie, technologické postupy a pod. Preto sa tím dopĺňa o ďalších špecialistov alebo sa menujú ďalšie realizačné tímy podriadené RKP. 3. RKP musí prispôsobovať svoje funkcie a organizačnú štruktúru prebiehajúcej fáze projektu. 42

43 Vedúci RKP Vedúci RKP je kľúčovou osobou RKP. Musí mať dobré poznatky o zásadách budovania IS, musí byť dobrým organizátorom a byť členom vedenia podniku: Najčastejšie ide o manažéra pre IS/IT (CIO). Musí mať rámcové poznatky o možnostiach a technických obmedzeniach technologických súčastí IS, nemusí byť však vysoko špecializovaným odborníkom na HW alebo SW ani na aplikačnú doménu príslušného komponentu IS, napr. financie, obchod, štatistiku, pod Metodik projektu Metodik projektu je tiež významnou osobou v RKP. Musí byť expertom na aplikačnú doménu práve realizovaného komponentu IS. Musí mať právomoc rozhodnúť o všetkých metodických otázkach projektu, napríklad o štruktúre číselníkov a ich nastavení.. Niektoré jeho rozhodnutia môžu podliehať schváleniu na úrovni vedenia podniku, najmä ak ide o zásah do existujúcej vnútro firemnej legislatívy. Metodik projektu taktiež môže súčasne pôsobiť ako metodik niektorého podprojektu. Špecifickou požiadavkou je, aby metodik vykonával svoju prácu ako náplň s najvyššou prioritou a nie ako prácu navyše Právomoci a ich zrozumiteľnosť v rámci vedenia projektu Hierarchia riadiacich funkcií je v podnikoch zvyčajne dobre zrozumiteľná a je prirodzene rešpektovanou subordináciou. Je teda známe, kto komu podlieha, kto je komu partnerom na rokovanie. Pri obslužných útvaroch podniku sa neočakáva že budú pracovať koncepčne a teda ani nie sú považované za rovnocenné pre rokovanie s vrcholovým vedením podniku. Tieto okolnosti je potrebné zobrať do úvahy aj pri riadení projektov zameraných na vybudovanie IS, pretože nezaistená subordinácia môže negatívne ovplyvniť riadenie projektu a tým jej jeho vykonateľnosť. Pre riadenie projektu IS je možné zvoliť rozličné štruktúry RKP. V zásade existujú 4 základné typy modelov riadenia IS podľa ďalej uvedenej tabuľky. Tabuľka súčasne ukazuje výskumom zistené percento vykonateľnosti pre jednotlivé modely riadenia realizácie projektu. Model riadenia A B C D Vykonateľnosť 35 % 40 % 50 % 60 % 43

44 Vysvetlivky ku modelom: A vedenie podniku musí postaviť servisnú jednotku (napr. VS, ktoré nie je súčasťou vrcholového vedenia) B je vytvorená nová riadiaca štruktúra paralelná k existujúcej štruktúre C Vedúcim projektu je člen vrcholového vedenia v roli námestníka D vedenie podniku je zastúpené námestníkom a závody sú zastúpené námestníkmi riaditeľov závodov. Rozdiely vo vykonateľnosti sú dané najmä rozsahom zrozumiteľnosti riadiacej štruktúry a dôveryhodnosti ich právomocí Zabezpečenie primeraných podmienok na riešenie projektu Aj v tomto prípade platí potreba dodržiavania zásad pre riadenie veľkých projektov. Projekt musí byť riadený podľa dôkladne premysleného, prerokovaného a schváleného plánu. Plán na realizáciu projektu IS by spravidla mal obsahovať: Rozdelenie každej akcie na logicky menšie celky hierarchickým spôsobom o najmenšou akciou by mala byť akcia v trvaní 2 týždňov, o každej najmenšej akcii je treba prideliť tieto atribúty: potrebný čas na prípravu a vykonanie, nadväznosť na predchádzajúce akcie, plánovaný kontrolovateľný výstup akcie, potrebné zdroje (personál s kvalifikáciou, financie, materiál, technické zabezpečenie, súčinnosť, priestory), zodpovednú osobu. Usporiadanie čiastkových akcií v časovom slede tak, aby súčasne: o boli v plnom rozsahu rešpektované požadované nadväznosti, o boli efektívne využité dostupné zdroje. Pomôckou pre prípravu a zobrazovanie plánu projektu, jeho dekompozície na akcie a časovanie je napr. Gantov diagram. Taktiež sa môžu využívať podporné nástroje ako je MS Project a iné. Súčasťou plánu projektu je aj jeho zabezpečenie organizačné, personálne, finančné a technické Organizačné zaistenie Každý podprojekt/subsystém IS má špecifické požiadavky na organizačnú štruktúru riadiacich a výkonných pracovníkov. 44

45 V organizačnej štruktúre musia byť zastúpené aj rôzne role koncových používateľov IS, pretože bez ich účasti na projekte je len ťažko možné na konci projektu získať ich spokojnosť s odovzdávaným riešením IS. Je potrebné dôkladne premyslieť aké riadiace a vykonávacie roly musia byť v danom projekte alebo subsystéme zastúpené. Projekt má mať hierarchickú organizačnú štruktúru s jasným vymedzením: kto komu podlieha rozsahu povinností a právomocí jednotlivých rolí. Nedôslednosť pri určovaní uvedených aspektov organizovania činností ľudí na projekte môže viesť k viackoľajnosti v riadení a kontraproduktívnemu riadeniu. Ďalším vážnym problémom projektu je zaistenie dobrej súčinnosti s dodávateľom IS. Dodávateľovi, resp. jeho pracovníkom pôsobiacim na projekte je potrebné vytvoriť dobré pracovné podmienky a prostredie. Je vhodné na obmedzenú dobu prideliť im miestnosť v priestoroch podniku. Takéto opatrenie výrazne zlepší súčinnosť dodávateľa s pracovníkmi podniku, vytvorí dobré podmienky pre konzultácie nad prototypom riešenia, najmä bude možné overovať správnosť pochopenia zadania s správne formulovanie prípadných korekčných opatrení v riešení. Z hľadiska organizácie prác na projekte je taktiež dobré už na začiatku projektu pamätať na umiestnenie základných technických zariadení ako sú servery, ktoré sú využívané na testovanie prototypov či konečných riešení v rámci akceptačných testov. Samotné testovanie je dôležitou súčasťou organizačného zabezpečenia projektu IS. Testovaním sa pritom rozumie overenie, či všetky funkcie dodaného systému odpovedajú potrebám používateľov, resp. zadaniu. Testovanie by tiež malo byť dobré zorganizované. Často sa uplatňujú dve úrovne testovania zo strany zadávateľa projektu a to: Jedno rázové testovanie, ktoré je súčasťou preberania komponentu IS Dlhodobé testovanie, ktoré spravidla býva organizované ako skúšobná prevádzka na ostrých dátach.. Významnou zložkou realizácie projektu IS je aj školenie používateľov, ktoré taktiež vyžaduje dobé organizačné zabezpečenie. Školenia okrem iného musia zabezpečiť, aby všetci používatelia boli podľa svojich rolí oboznámení ešte pred nasadením nového systému do ostrej prevádzky so všetkými funkciami pre príslušnú rolu a so zmenami v organizácii práce po nasadení nového systému a tiež aby absolvovali nácvik ovládania nového systému. Významnou zložkou školení je aj oboznámenie sa a nácvik využívania bezpečnostných mechanizmov zahrnutých do samotných aplikácií a prostredia využívania IS. 45

46 Treba pamätať nato, že používatelia IS posudzujú nový IS očami doterajších pracovných návykov a skúseností. Preto je potrebné upozorniť ich na všetky odlišnosti voči starému systému a to vrátane usporiadania výstupných zostáv Personálne zaistenie Jedným z predpokladov úspešného napredovania projektu je aj poskytovanie primeranej súčinnosti zo strany podniku - zadávateľa projektu nového IS vo vzťahu k riešiteľovi, či dodávateľovi nového IS. Vecným obsahom je najmä personálna súčinnosť. Zo strany podniku je potrebné personálne pokryť všetky aktivity projektu. Týka sa to tak technických činností ako sú správa systému, správa sietí, správa databázy a pod. ako aj činnosti špecializovaných ako sú správa aplikácií pre jednotlivé komponenty systému. Je užitočné menovať zodpovedného pracovníka za každý komponent systému. Jeden pracovník môže pritom byť garantom viacerých komponentov. Dôležitým aspektom účasti ľudí na projekte je, aby kľúčové roly boli vykonávané ako hlavná pracovná náplň. Taktiež treba pamätať na zastúpiteľnosť ľudí, najmä na kľúčových postoch. Už bolo spomínané, že úspech projektu by mal byť podporovaný aj správnou motiváciou pracovníkov zúčastnených na projekte. Je vhodné ak na postoch vedúcich pracovníkov sú ľudia zapálení pre IT, ktorí sú ochotní pracovať s vysokým nasadením a súčasne aby ich aktivity boli zo strany vedúcich pracovníkov podporované dobrou finančnou motiváciou, ale aj vhodným morálnym ocenením výnimočných výkonov pri realizácii projektu Finančné zaistenie Pri realizácii projektu zameraného na vybudovanie nového IS je potrebné súčasne, ako aj postupne financovať veľký počet rôznych položiek. Patria medzi ne napríklad: vývojové práce, tvorbu dokumentácie, nákup HW a základného softvéru, budovanie sieťovej infraštruktúry, služby, prevádzkové náklady, mzdy a cieľové odmeny, školiacu činnosť a mnohé ďalšie. 46

47 Skúsenosti z praxe dokazujú, že len dostatočne silný rozpočet pre projekt IS môže zaistiť kvalitné výsledné riešenie IS. Na druhej strane škrtenie výdavkov na takýto projekt vždy znamená obmedzenia vo funkčnosti, spoľahlivosti či bezpečnosti nového IS a často aj k malému používateľskému komfortu, pričom dobrý používateľský komfort mal byť samozrejmosťou. Poznatky z praxe taktiež dokazujú, že odstraňovanie nedostatkov vzniknutých škrtením rozpočtu projektu vždy vyústia do omnoho vyšších dodatočných nákladov voči tým, ktoré boli pôvodne plánované a zo strany podniku nie v plnej hodnote poskytnuté Technické zaistenie Zavádzanie a prevádzka nového IS vždy potrebuje nejakú technickú infraštruktúru, ktorá obvykle v nejakom rozsahu už v podniku existuje. Technické zaistenie projektu spravidla zabezpečuje útvar informatiky podniku, ktorý zvyčajne má vo svoje pôsobnosti okrem iných najmä tieto činnosti: správa systémov, správa sietí, správa databáz, správa aplikácii, údržba HW, prevádzka IS, zálohovanie a archivovanie dát, zaisťovanie externých služieb, rozvoj HW a SW platformy systému. Útvar informatiky podniku musí byť vhodne zakomponovaný do organizačného zabezpečenia projektu IS aby mohol splniť svoje poslanie v priebehu vytvárania, testovania, ale najmä začatia ostrej prevádzky nového IS. Dôležité je aj správne vymedzenie právomocí a kompetencií útvaru informatiky v kontexte riadenia projektu Kontrolná činnosť Medzi základné nástroje pre účinné riadenie projektu IS patrí aj kontrolná činnosť. Všeobecne platí, že aj dobre naplánovaný projekt je potrebné kontrolovať z hľadiska jeho napredovania v súlade so schváleným plánom. V praxi často vznikajú odchýlky, ktoré je potrebné včas rozpoznať, podľa potreby vykonať nápravu, prípadne vyvolať a realizovať zmeny v pláne projektu. 47

48 Kontrolná činnosť sa musí zameriavať najmä na: dodržiavanie harmonogramu jednotlivých akcií, vecnú správnosť jednotlivých činností, čerpanie finančných prostriedkov. Nesmie sa zabúdať na overovanie stavu súčinnosti medzi útvarmi podniku a dodávateľom IS, ani na súčinnosť s inými subjektmi ako sú rôzny subdodávatelia. Schválený plán projektu IS musí byť považovaný za záväzný pre všetkých účastníkov projektu. Odchýlky voči plánu projektu musia byť posudzované prísne ale aj objektívne a musí byť vyvodzovaná osobná zodpovednosť za neplnenie plánovaných úloh. Ak účastníci nerešpektujú záväznosť plánu projektu môže dôjsť k postupnému nárastu problémov pri jeho realizácií a projekt sa môže stať neriaditeľným. Dokumentovanie zistených problémov počas realizácie projektu je vhodné podporiť formulárom pre zaznamenávanie udalostí. Súčasne je potrebné vylúčiť riešenie nejasne definovaných problémov. Vylúči sa tým okrem iného situácia, keď ohlasovateľ problému ani nerozumie problému, vlastne presne nevie o čo ide, ale zámerne vytvára nepriaznivé povedomie o problémoch počas realizácie projektu. Bez informácií získavaných kontrolnou činnosťou počas realizácie projektu IS nie je možné zaistiť efektívne a účinné riadenie priebehu projektu zo strany riadiacich orgánov vytvorených pre riadenie projektu. 48

49 4.2.6 Príprava a realizácia projektu Problematika prípravy a realizácie projektu je ďalej členená na tieto oblasti: Poslanie RKP vo fáze prípravy. Definovanie HW a SW platformy IS. Rozhodnutie o dodávateľovi IS. Architektúra a topológia systému. Typové riešenie. Výberové konanie. Zmluva s dodávateľom Poslanie RKP vo fáze prípravy Poslaním tejto fázy projektu zameraného na budovanie nového IS je spracovať rozhodnutia o informačnej stratégií podniku do podoby, ktorá umožní realizáciu tejto stratégie. Tomuto cieľu musí byť prispôsobená aj činnosť RKP. Na základe existujúcich strategických zámerov podniku je potrebné pripraviť materiály pre rozhodovanie vedenia podniku o ďalšom postupe. základné Materiály by mali byť zamerané na: posúdenie existujúceho stavu riadenia podniku a potvrdenie strategických zámerov pre ďalšie obdobie, formulovanie základných podmienok, postupov a nárokov na výber riešenia, ktoré naplní strategické zámery v oblasti IS, určenie základných časových horizontov pre ďalšie kroky. Na základe uvedených dokumentov RKP rozhodne o ďalšom postupe. Výsledkom fázy musí byť: rámcový plán úloh, harmonogram priebehu, rámcová ekonomická úvaha o potrebných zdrojoch. Fáza by nemala trvať príliš dlho, najviac cca 3 mesiace. Vhodné je, ak sa využíva externá poradenská firma skúsená z hľadiska prípravy projektu zameraného na budovanie IS. RKP pripraví 3 ďalšie dokumenty mapujúce: požiadavky podniku na IS, stav v podobných podnikoch, ktoré už majú podobný IS, dostupnosť softvéru vhodného pre predmetný IS na trhu. 49

50 Požiadavky podniku na IS Odporúčaná štruktúra informácií obsiahnutých v dokumente je nasledovná: hrubá architektúra a topológia nového IS, určenie postupu riešenia z hľadiska priorít vedenia podniku, definovanie základného prostredia pre prevádzku IS, návrh rozhodnutia o spôsobe vývoja, základné ekonomické úvahy, návrh personálneho zabezpečenia jednotlivých krokov počas budovania IS, väzbe na existujúci IS a rámcové okolnosti migrácie dát, hodnotenie dostupných typových riešení, návrh uznesenia vedenia podniku o ďalšom postupe Dodávka IS špecializovanou firmou Z hľadiska spôsobu vývoja nového IS sú k dispozícií dve základné možnosti a to: vlastný vývoj, vývoj a dodávka IS vybraným dodávateľom. Ak vedenie podniku rozhodne o dodávke IS špecializovanou firmou potom RKP zabezpečuje najmä tieto kroky: príprava výberového konania, špecifikácia podmienok koordinácie s ďalšími relevantnými stranami, realizácia a vyhodnotenie výberového konania, príprava rozhodnutia vedenia podniku o nákupe vybraného riešenia. Potom čo vedenie podniku rozhodne o nákupe nového IS od vybraného dodávateľa musí nasledovať krok určenia pravidiel pre budúcu spoluprácu s dodávateľom IS. Na základe vlastnej firemnej predstavy a návrhov dodávateľa vznikne podklad pre zmluvu s dodávateľom nového IS. Finálnym krokom fázy je príprava a podpísanie zmluvy o dielo, ktorej predmetom plnenia je dodávka nového IS Definovanie HW a SW platformy IS Podrobný návrh HW a SW platformy IS bude predmetom a výsledkom neskorších etáp projektu zameraného na vybudovanie nového IS. 50

51 Napriek tomu už v prípravnom období je potrebné definovať základný rámec technického prostredia budúceho IS vzhľadom na: výkon celého systému, spoľahlivosť systému, bezpečnosť systému. V rámci tohto kroku sa musí určiť: kategória OS, kategória databázového serveru (hardvér), kategória databázového systému (softvér). Kategória OS Všeobecne platí, že existujú dva základné alternatívy a to: MS Windows a UNIX. Skúsenosti z praxe ukazujú, že pre náročné profesionálne IS sa platforma UNIX ukazuje ako systém s veľkou robustnosťou, vysokou spoľahlivosťou a dobrou odolnosťou voči vírusom. Všeobecne taktiež platí, že náchylnosť MS Windows na bezpečnostné slabiny je všeobecnej výšia, aj keď na druhej strane sú známe aj rozsiahle a pomerne stabilné a bezpečné riešenia IS založených na tom OS. Databázový server V súčasnosti existuje na trhu široká paleta počítačov vhodných na použitie ako databázový server. Je potrebná zvoliť taký počítač, ktorý je: schopný pracovať spoľahlivo pod zvoleným OS, má dostatočný výkon procesora/ procesorov, má dostatočnú operačnú pamäť, pracuje s veľkokapacitnými diskami alebo diskovými poliami. Pre často kritický parameter IS, ktorým je doba odozvy je kritická najmä veľkosť operačnej pamäte. Kritickým faktorom z hľadiska odozvy u relačných databáz je tiež rýchlosť prístupu k dátam na disku. Výrobcovia často odporúčajú využívať viac menších diskov. Databázový systém Výber databázového systému má veľký vplyv na budúce vlastnosti nového IS. 51

52 Pre rozsiahle IS nie je možné odporúčať tzv. laické databázy napríklad Access, ktorý je určený pre malé aplikácie. Je potrebné sa orientovať na profesionálne veľké databázové systémy renomovaných tvorcov a dodávateľov ako sú: Oracle Informix MS SQL a ďalšie. S týmito databázovými systémami je totiž spojená aj určitá vyššia záruka za integritu a bezpečnosť dát Rozhodnutie o dodávateľovi IS Úvodom je nutné konštatovať, že nie každý podnik má svoje vlastné vývojové oddelenie pre vývoj SW a nie každé existujúce podnikové oddelenie je schopné zvládnuť všetok vývoj potrebný v súvislosti s budovaním nového IS. Na druhej strane platí, že útvar informatiky podniku je zvyčajne považovaný za centrum exelencie vo všetkých záležitostiach IT a komunikačnej techniky. Existujúce tímy veria vo svoje tvorivé sily a schopnosti. Voči uvedenému často nie je možné vôbec namietať, problémom môže byť len efektívnosť rôznych možností. Väčšinou pre prípad rozsiahleho IS platí, že podnikový útvar informatiky len ťažko je schopný konkurovať profesionálnym producentom SW. Pri rozhodovaní o vlastnom vývoji alebo o kúpe nového IS od vybraného dodávateľa preto často rozhoduje odpoveď na otázku: Čo je ľahšie a lacnejšie? 1. Kúpiť hotové riešenie od profesionálneho dodávateľa? 2. Vyvíjať vlastné podnikové na mieru ušité riešenie? Pre manažérov podnikov môžu byť veľmi užitočné nasledujúce všeobecné platné poznatky o kladoch a nedostatkoch oboch skôr uvedených možnosti: 52

53 Vlastný vývoj Výhody: vývoj zabezpečujú pracovníci podniku znalosť podnikového prostredia jednoduchšia komunikácia v rámci pracovných kontaktov Nevýhody: menšie skúsenosti z hľadiska metodológie vývoja menšie schopnosti z hľadiska expertíz v aplikačnej oblasti slabšie vybavenie pre vývoj nástrojmi niekedy slabá motivácia ľudí častá migrácia špecialistov niekedy neschopnosť dlhodobého udržiavania riešenia a jeho rozvoja Externý dodávateľ Výhody: špecializovaný a skúsený personál skúsenosť zo zavádzania IS v iných podnikoch preberanie dobrých riešení z iných projektov personál pre špecifické aplikácie výkonné vývojové prostredie dbá na kvalitu vytváraného diela snaha uplatňovať najnovšie technológie Nevýhody: väčšia vzdialenosť medzi riešiteľom a používateľom zložitejšia koordinácia prác medzi dodávateľom a útvarmi odberateľa menšia znalosť miestneho prostredia a podnikovej kultúry Aj keď rozhodovanie o spôsobe vývoja nového IS závisí od konkrétnych podmienok, je možné formulovať niekoľko všeobecne platných zásad, ktoré by mali byť zvažované pri rozhodovaní: Podniky by nemali vyvíjať rozsiahle IS vlastnými silami, Kde je to možné uplatniť typové riešenie, IS budovať v úzkej súčinnosti externého dodávateľa a podnikového útvaru informatiky. V súvislosti s vývojom nového IS je potrebné ešte spomenúť tzv. outsourcing. O čo teda ide? Ide o riešenie, kedy podnik sám nič nevlastní a neprevádzkuje ale objedná si informačnú obsluhu všetkých alebo určitých procesov od externej špecializovanej firmy. Problémom jeho širšieho využívania je najmä to, že podniky sa boja zveriť príliš veľa práv nad svojimi dátami a procesmi externému partnerovi a súčasne malá dostupnosť takýchto služieb zo strany špecializovaných firiem s dobrým obchodným menom. 53

54 Architektúra a topológia systému Platí, že už vo fáze prípravy je potrebné premyslieť rámcovú architektúru a topológiu budúceho nového IS. Architektúra a topológia systému by mala byť súčasťou zadania pre uskutočnenie výberového konania pripravovaného zo strany podniku. Architektúra a topológia systému v predkladaných riešeniach musí rešpektovať: individuálnu vnútornú štruktúru podniku, počet a lokality rozmiestnenia pracovísk podniku, spôsob komunikácie medzi pracoviskami vzhľadom na objemy prenášaných dát, nutnosť on-line prevádzky, náklady na vybudovanie infraštruktúry a pod. Je jasné, že nejaké riešenie IS potrebuje podnik nachádzajúci sa v jednej budove a iné riešenie potrebuje podnik majúci 50 pracovísk v rámci územia štátu, či v rámci viacerých štátov s rozdielnym politickým a kultúrnym prostredím. Podstatnou požiadavkou pre návrh architektúry a topológie IS je dosahovanie potrebnej bezpečnosti prevádzky IS. Rámcová architektúra a topológia IS musí špecifikovať najmä: návrh rozdelenia IS na jednotlivé zamýšľané komponenty, ich základné rozdelenie na moduly, základné väzby medzi definovanými časťami IS. Odporúčaná štruktúra rámcovej architektúry a topológie IS je táto: konceptuálny model, zoznam komponentov IS s opisom ich požadovaných funkcií, požadované väzby medzi komponentmi, rozdelenie komponentov na nové a existujúce, definovanie prostredia, v ktorom budú komponenty IS prevádzkované o OS, o HW a SW platforma, stručný opis lokalít, v ktorých majú byť komponenty IS prevádzkované, opis navrhovanej, resp. akceptovateľnej architektúry o centrálna, o distribuovaná, špecifikácia požadovaného druhu prevádzky o v reálnom čase, o dávkové spracovanie, o prenos dát v dohodnutých intervaloch,.. a ďalšie. 54

55 Poznamenávame, že v žiadnom prípade nejde o nejaký detailný opis. Hĺbkovú analýzu a návrh riešenia musí neskôr vykonať vybraný dodávateľ nového IS. V tejto etape rozmýšľania o novom IS o pochopenie toho: ide zo strany podniku budujúceho nový IS čo nakúpime, čo upravíme, čo urobíme sami, čo sme ochotný použiť inak ako doteraz, čo sme ochotný nahradiť úplne niečím novým, čo chceme ďalej používať bez zmien a pod. Ak poznáme odpovede na uvedené otázky môžeme pomocou odborníkov urobiť prvý náčrt budúcich nákladov súvisiacich s novým IS a potom v súlade s o záujmami a možnosťami podniku rozhodovať o ďalšom postupe Typové riešenie Dynamicky sa rozvíjajúce podnikateľské aktivity podnikov a s tým súvisiaci dynamický rozvoj ich IS je významnou charakteristikou súčasnosti. Často platí, že mnohé oblasti podnikových činností, ktoré môžu pokrývať obslužné IS sú v mnohých podnikoch rovnaké alebo veľmi podobné. To dáva možnosť zvažovať hneď niekoľko možností pri budovaní nového IS a to: nebrať ohľad na iných a vytvoriť vlastné podnikové riešenie, využívať poznatky iného podniku, ktorý už má takýto IS implementovaný, využívať možnosti typového riešenia renomovaného dodávateľa IS, ktorý navyše takýto alebo podobný IS implementoval niekoľko krát u iných podnikov. Je jasné, že: využívanie poznatkoch iných prináša výhody, využívanie skúseného dodávateľa s niekoľkonásobnou aplikáciou takéhoto IS alebo podobného IS tiež prináša výhody. Určite platí, že: väčšie množstvo súčasne zavedených alebo prevádzkovaných inštalácií nejakého IS umožňuje vyvíjať tlak na dodávateľa, aby pomerne rýchlo zabezpečoval potrebné úpravy, dodávateľ typového riešenia má skúsenosti s rôznym podnikovým prostredím, takže svoje poznatky môže využívať veľmi efektívne aj v našom podniku. Taktiež môže lepšie zhodnotiť dopady našich alebo jeho vlastných požiadaviek na úpravy typového riešenia. 55

56 Výberové konanie Výberové konanie je veľmi dôležitým krokom potom, čo sa podnik rozhodol pre realizáciu nového IS dodávateľským spôsobom. Podotýkame, že výberové konanie je vhodným krokom nielen pre tých, ktorým to vyplýva zo zákona, ale aj pre tých, ktorí takúto povinnosť zo zákona nemajú, avšak potrebujú sa dobre a najmä objektívne rozhodnúť počas výberu dodávateľa IS. Keďže v druhom prípade záleží výhradne na podnikových pravidlách pre prípravu, realizáciu a vyhodnotenie výberového konania, definujeme v tejto časti skrípt základné zásady prípravy a realizácie výberového konania pre výber dodávateľa nového IS podľa platného zákona č. 25/ 2006 Z.z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov. Všeobecne platí, že pomocou dokumentácie vypracovanej a schválenej v predchádzajúcich krokoch je možné rozhodovať aj o spôsobe vykonania výberového konania pre nový IS. Pri príprave výberového konania je potrebné najmä: určiť stratégiu a taktiku rokovania s možnými dodávateľmi, či systémovými integrátormi, rozhodnúť, či bude vybraný systémový integrátor, ktorý bude riadiť ďalší postup, alebo systémovým integrátorom bude RKP podniku, rozhodnúť o spôsobe schvaľovania jednotlivých krokov výberového konania, určiť predpokladaný termín nasadenia nového IS, rozhodnúť o tom, či podnik bude IS prevádzkovať sám alebo využije outsourcing, rozhodnúť, ktoré časti IS budú realizované a v akom poradí, určiť požiadavky na komponenty IS, ktoré sú predmetom výberového konania, navrhnúť postup pri overovaní vlastností ponúkaných IS, rozhodnúť o tom, či výberové konanie sa týka celého IS, alebo pre každú časť IS bude organizované samostatné výberové konanie, rozhodnúť či dávame prednosť dodávateľovi s niekoľkými implementáciami takéhoto alebo podobného IS, rozhodnúť či dávame prednosť typovému riešeniu, rozhodnúť či budeme spolupracovať s inými podnikmi, rozhodnúť či budeme viazaný maximálnou cenou, rozhodnúť či o spôsobe financovania IS a uvoľniteľných čiastkach v jednotlivých rokoch budovania nového IS. Z uvedeného zoznamu krokov je jasné, že príprava výberového konania nie je jednoduchou záležitosťou. Existujú však dva spôsoby, ktoré môžu postup výberového konania zjednodušiť. 56

57 Ide o tieto postupy: vyberieme systémového integrátora (cez výberové konanie), ktorý potom vyberie dodávateľov jednotlivých komponentov IS, zvolíme aplikáciu typového riešenia, alebo riešenia použitého v inom podniku, čo umožní napodobniť postup. V prvom prípade RKP organizuje len výberové konanie pre výber systémového integrátora. Vybraný systémový integrátor potom organizuje ďalšie výberové konania. Dôležité je presné špecifikovanie súčinnosti RKP pri výberových konaniach organizovaných systémovým integrátorom, ako aj rozhodnutie o tom, či sa môže on stať dodávateľom niektorých častí nového IS. V druhom prípade podnik za nejakú čiastku získa vzorové podklady, ktoré ľahko prispôsobí svojim podmienkam. Výsledkom prípravných prác pre výberové konanie je špecifikácia podmienok verejnej zákazky, ktoré sa spravidla skladajú zo základného materiálu a niekoľkých príloh obsahujúcich podrobnejšie špecifikácie. Závisí od konkrétnych podmienok v akom rozsahu sa na ich príprave podieľa RKP a systémový integrátor, prípadne externá poradenská firma Zmluva s dodávateľom Obsah zmluvy je v praxi veľmi závislý od zvyklostí konkrétneho objednávateľa a dodávateľa. Na druhej strane existuje rad okruhov, ktoré by mali byť ošetrené v každej zmluve týkajúcej sa budovania nového IS. Všeobecne platí, že zmluvný vzťah je najčastejšie uzatváraný na základe Obchodného zákonníka v platnom znení. Právnu stránku zmluvného vzťahu s dodávateľom nového IS najčastejšie rieši podnikovú právny útvar, prípadne externá advokátska kancelária. Medzi základné podmienky zmluvného vzťahu, ktoré je vhodné prerokovať s dodávateľom vopred patria najmä: o štruktúra zmluvy, o predmet plnenia ( skrýva v sebe rozsah budovaného IS), o rozsah zmluvných dokumentov, o harmonogram plnenia, o cena diela a prípadné zľavy, o platobné podmienky, o reklamačné podmienky, o zmluvné zaistenie budúcich požiadaviek, o pravidlá pre riadenie projektu a ďalšie. V prípade, že bol vybraný systémový integrátor, potom hlavný zmluvný vzťah je nadviazaný s ním a zmluvy s konkrétnymi subdodávateľmi rieši systémový integrátor. 57

58 Problémom zmluvného vzťahu je vždy dôvera medzi zmluvnými stranami. Tu platí to, že nedostatok dôvery nie je možné nahradiť príliš detailnou zmluvou, pretože množstvo potenciálnych sporov prekryje pôvodný dobrý úmysel jasných detailných pravidiel pre spoluprácu a najmä.plnenie zo strany dodávateľa a projekt ani spolupráca nebudú napredovať tak, ako by bolo potrebné. Je treba si uvedomiť, že je lepší dodávateľ, ktorý súhlasí s dobre často detailne rozpracovanou zmluvou než ten, ktorý na začiatku sľúbi všetko avšak pri praktickom plnení zmluvy veľmi často používa formuláciu: to nie je v zmluve. Ďalší vážny problém je definovanie požiadaviek podniku na IS, teda budúceho používateľa nového IS. Nejasne definované požiadavky, často menené požiadavky komplikujú systémové riešenie a môžu znamenať predlžovanie doby riešenia a koniec koncom aj oddialenie termínu implementácie nového riešenia IS. Je vhodné, ak pri definovaní požiadaviek podniku na nový IS participuje aj vybraný systémový integrátor. Ak softvérový dom chce získať zákazku, obvykle súhlasí zo všetkým. To však pre normálny pracovný život nemôže stačiť. Najmä pri doplňovaní systému je potrebné od dodávateľa požadovať podrobný postup plnenia a to ešte pred uzatvorením zmluvy. Dĺžka trvania zmluvného vzťahu a najmä doby trvania riešenia IS a jeho dodávky je ďalší vážny problém. Dobrým riešením pre podnik je, keď jednotlivé komponenty v praxi často nazývané podsystémy alebo moduly IS zazmluvňuje systémový integrátor, ktorý vykonáva vrcholovú koordináciu realizácie projektu. Pre Podnik a samotnú RKP odpadá množstvo sporov týkajúcich sa časového plnenia či neplnenia zo strany jednotlivých subdodávateľov. Celý zmluvný vzťah by mal mať na starosti jeden člen RKP, ktorý je ostatnými členmi RKP kontrolovaný. Potom je možné zo strany zástupcov podniku rýchlo riešiť vznikajúce problémy. Dôkladné dokumentovanie zmluvného vzťahu, všetkých rokovaní a protokolárne vzájomne odsúhlasovaných dohôd je základom korektných vzťahov medzi podnikom ako odberateľom nového IS a dodávateľom ako tvorcom a implementátorom nového IS. Bezproblémovému priebehu spolupráce prispievajú aj vhodne zvolené kontaktné osoby charakteristické schopnosťou komunikovať s inými ľuďmi a schopnosťou uzatvárať rozumné kompromisy. Nie je žiaduca častá výmena kontaktných osôb, pretože to naruší už vybudované medziľudské vzťahy a skomplikuje to zavedený priebežný proces utriasania projektu medzi riešiteľmi a odberateľom. Je potrebné ešte spomenúť problém kvality účastníkov projektu. To, že sa od dodávateľa vyžaduje vysoko odborný a skúsený personál je už samozrejmé. Častým problémom praxe však je, že na protistrane, teda na strane podniku to tak nie je. Preto podnik pripravujúci projekt zameraný na vybudovanie nového IS sa musí vopred nato pripraviť, okrem iného aj doškolením vlastných zamestnancov, či náborom odborníkov pre zamýšľané HW a SW prostredie nového IS. 58

59 Samostatným problémom, ktorý vyžaduje maximálnu pozornosť je zabezpečenie bezpečnosti nového IS počas jeho projektovania, vývoja a následne počas prevádzky. V rámci uzatváraných zmlúv musia byť vyriešené aj otázky bezpečnosti IS pri jeho projektovaní a vývoji. Len dodávame, že požiadavky na IS špecifikované zo strany podniku musia tiež obsahovať požiadavky na budúcu bezpečnosť nového IS. Existuje rad odporúčaní, čo by zmluva hľadiska obsahovať. o vývoji nového IS mala z bezpečnostného Určité zovšeobecnenie v tomto smere poskytujú medzinárodné normy, napr. ISO/IEC a ďalšie, z ktorých možno odvodiť takúto špecifikáciu: Nasledovné podmienky by mali byť zvážené a následne zahrnuté do zmluvy, čím sa dosiahne naplnenie identifikovaných bezpečnostných požiadaviek: a) politika informačnej bezpečnosti; b) opatrenia na zabezpečenie ochrany aktív, vrátane: 1. procedúr na ochranu aktív organizácie, vrátane informácií, softvéru a hardvéru; 2. akékoľvek nevyhnutné opatrenia a mechanizmy fyzickej ochrany; 3. opatrenia na ochranu pred škodlivým softvérom; 4. procedúry na určenie toho, či došlo ku kompromitácií aktív, napr. strata alebo modifikácia informácií, softvéru a hardvéru; 5. opatrenia na zabezpečenie návratu a zničenia informácií a aktív po vypršaní platnosti dohody alebo v inak stanovenom termíne; 6. dôvernosť, integrita, dostupnosť a akékoľvek iné relevantné vlastnosti aktív; 7. obmedzenia kopírovania a odkrytia informácií a použitie zmlúv o zachovaní dôvernosti; c) školenia používateľov a administrátorov v oblasti metód a procedúr bezpečnosti; d) zabezpečenie používateľského povedomia v súvislosti s otázkami a zodpovednosťami informačnej bezpečnosti; e) doložka o presune personálu, v prípade potreby; f) zodpovednosť v súvislosti inštaláciou a údržbou hardvéru a softvéru; g) jednoznačná štruktúra a formát tvorby správ; h) jednoznačný a bližšie špecifikovaný proces riadenia zmien; i) politika riadenia prístupu pokrývajúca: 1. rozličné dôvody, požiadavky a výhody pre ktoré sa prístup tretích strán stáva opodstatneným; 2. povolené metódy prístupu a kontrola a použitie unikátnych identifikátorov akými sú ID používateľov a heslá; 3. autorizačný proces pre prístup používateľov a privilégiá; 4. požiadavka viesť zoznam jednotlivcov autorizovaných na použitie služieb, ktoré boli sprístupnené a toho, aké sú ich práva a privilégiá pokiaľ ide o takéto použitie; 5. stanovisko, v ktorom sa uvádza, že akýkoľvek prístup, ktorý nie je explicitne povolený je zakázaný; 6. proces obnovy prístupových práv alebo prerušenie spojenia medzi systémami; 59

60 j) pravidlá týkajúce sa oznamovania, signalizovania a vyšetrovania incidentov a narušení informačnej bezpečnosti, ako aj nesplnenia požiadaviek uvedených v zmluve; k) opis každého produktu a služby, ktoré majú byť poskytnuté a opis informácií, ktoré majú byť sprístupnené vrátane ich bezpečnostnej klasifikácie; l) cieľová úroveň služieb a neprijateľná úroveň služieb; m) definícia overiteľných kritérií výkonnosti, ich monitoring a vykazovanie; n) právo monitorovať a stornovať akúkoľvek aktivitu spojenú s aktívami dodávateľa; o) právo auditovať zodpovednosti zadefinované v zmluve, možnosť nechať si audit realizovať treťou stranou a vymenovať štatutárne práva audítorov; p) zavedenie eskalačného procesu riešenia problémov; q) požiadavky na kontinuitu služieb, vrátane mier dostupnosti a spoľahlivosti a to v súlade s obchodnými prioritami organizácie; r) jednotlivé záväzky medzi organizáciou a druhou zmluvnou stranou a naopak; s) zodpovednosti s ohľadom na právne otázky a spôsob, akým sa zabezpečí, že budú tieto požiadavky naplnené, napr. legislatíva o ochrane dát, najmä berúc do úvahy rôzne právne systémy v rôznych štátoch v prípade ak dohoda zahŕňa aj spoluprácu so zákazníkmi v inej krajine; t) práva duševného vlastníctva, špecifikácia ochrannej známky a ochrana akejkoľvek spoločnej práce; u) spolupráca so subdodávateľmi v pozícii tretích strán a bezpečnostné opatrenia, ktoré subdodávatelia musia implementovať; v) podmienky prehodnotenia/stornovania zmlúv: 1. havarijný plán by mal byť zavedený pre prípad, ak sa ktorákoľvek zo strán rozhodne ukončiť zmluvný vzťah pred vypršaním jeho platnosti; 2. prehodnotenie dohôd v prípade zmeny bezpečnostných požiadaviek organizácie; 3. aktuálna dokumentácia zoznamy aktív, licencie, dohody a práva s nimi súvisiace. 60

61 4.2.7 Implementácia IS Časť autorov poníma implementáciu IS ako záverečnú časť nasadzovania vybraného riešenia IS, pri ktorej dochádza k postupnému zavádzaniu jednotlivých komponentov IS (resp. ich modulov) do prevádzky v podniku, ktorý objednal vybudovanie IS. Ide teda o časový interval kedy si okrem iného požívatelia musia osvojiť používanie nového IS. Logickou otázkou je: A kedy sa zavádzaný modul naprojektuje, naprogramuje a otestuje atď., keď ho už ideme zavádzať? Odpoveďou je, že implementácia IS je v takomto prípade ponímaná v plnom rozsahu, teda vrátane naprojektovania a naprogramovania, ako aj ďalších činností. Ďalej uvádzame opis procesu implementácie IS rozhodnuté o dodávke IS od externého dodávateľa. vychádza z predpokladu, že bolo Uvádzaný opis postupu je prispôsobený situácii, keď systémový integrátor koordinuje implementáciu IS v spolupráci s ďalšími subdodávateľmi Projekt realizácie IS Jednotlivé komponenty nového IS môžu byť definované v štúdii Informačná stratégia podniku alebo v Investičnom zámere alebo Inovačnom zámere. V tomto smere závisí len od podnikových zvyklostí. Typickými komponentmi/podsystémami podnikového IS sú napríklad: Technická príprava výroby, Výroba, Služby, Financie, Obchod, Marketing a podobne. Každý komponent sa spravidla skladá z viacerých modulov, pričom každý modul má určitú ucelenú funkčnosť. Napríklad v prípade komponentu/ subsystému Financie môže isť o moduly ako sú Záväzky, Pohľadávky, Pokladňa a ďalšie. Implementácia prebieha spravidla po jednotlivých komponentoch alebo sa súčasne zavádza niekoľko komponentov nového IS. Je zrejmé, že postup implementácie komponentu IS je možné štandardizovať a teda využívať v určitom rozsahu jednotný postup, aj keď pôjde o implementovanie komponentov z rôznym funkčným poslaním v rámci IS. Aby pri implementácii komponentu IS nedochádzalo ku živelnosti a chaosu je nutné ešte pred začatím implementácie samotného komponentu vypracovať základný dokument projektu, v praxi často nazývaný Realizačný projekt IS, alebo Projekt realizácie IS. 61

62 Tento projekt musí byť vzájomne odsúhlasený medzi dodávateľom a podnikom ako odberateľom. Odsúhlasené musia byť aj jeho všetky zmeny, pretože zvyčajne znamenajú zásadnú zmenu v implementácii IS v podniku. Zrejme je jasné, že Projekt realizácie IS je vlastne súborom jednotlivých komponentov IS. projektov realizácie Projekt realizácie komponentu sa spravidla člení na niekoľko podprojektov. Podprojekty sa realizujú po jednotlivých etapách a pre tieto etapy musia byť okrem iného definované najmä: o vecný obsah, o zodpovednosť, o termíny plnenia. Realizačný projekt komponentu opisuje postup implementácie konkrétneho SW, ktorý bude prevádzkovaný na konkrétnej HW platforme tak, aby boli naplnené funkcie očakávané alebo požadované od príslušného komponentu IS. Základná štruktúra realizačného projektu komponentu IS závisí od viacerých faktorov medzi ktoré patria najmä odpovede na uvedené otázky: o Ide o implementáciu prvého komponentu nového IS alebo ďalšieho komponentu? o Ide o prvú dodávateľovu implementáciu alebo už pokračujúcu implementáciu? o Nový IS sa buduje na zelenej lúke alebo predchádzajúce riešenie je viac menej akceptované a bude v modifikovanej verzii použité, či existujúci IS bude využitý len ako zdroj dát, ktoré budú migrované do nového IS? Ďalej uvádzame opis projektu realizácie komponentu IS za situácie keď ide o prvú implementáciu komponentu IS jedným z dodávateľov. Podstatnou informáciou je, že aj keď je už známe rozdelenie komponentu na moduly, toto členenie ešte nie je z hľadiska praktickej implementácie postačujúce, modul je potrebné ďalej členiť. Projekt realizácie komponentu potom: o rozčleňuje implementáciu na jednotlivé tématické oblasti definované v rámci modulu (ich súčasťou musí byť aj riešenie bezpečnosti spracúvaných dát), o špecifikuje spôsob vyhodnocovania postupu prác, o špecifikuje spôsob riešenia vznikajúcich problémov, o určuje zodpovedných pracovníkov, o určuje časové termíny, o určuje náklady, o vyhodnocuje rizika, o určuje stupeň dôležitosti čiastkovej témy vzhľadom na celkové riešenie modulu, podsystémy a systému ako celku. 62

63 Základná štruktúra realizačného projektu Základná štruktúra realizačného projektu sa zvyčajne skladá z troch projektov, tak ako je to znázornené obrázkom č. 4-2: o o o úvodná/rozdielová štúdiá, určenie postupov, spôsob realizácie. Obrázok č. 4-2 Štruktúra realizačného projektu Každý čiastkový projekt rieši relatívne samostatnú a ucelenú časť implementácie systému. Pre jeho riadenie je určený samostatný tím, harmonogram a rozpočet. V prípade realizácie IS v malých podnikoch je možné zlučovanie dvoch čiastkových projektov do jedného. Každý čiastkový projekt sa skladá z etáp a tie sa skladajú z krokov. Etapy vyjadrujú časovú postupnosť činností v rámci čiastkového projektu. Kroky vyjadrujú opis činnosti v rámci etapy a môžu byť vykonávané aj v inom poradí. 63

64 Úvodná štúdiá Úvodná štúdiá obsahuje spravidla: o o o definíciu cieľov, analýzu nahradzovaného stavu, špecifické požiadavky, pre zavádzanú časť IS. Iným prípadom je Rozdielová štúdiá, pri ktorej sa vychádza z toho, že vybraná časť IS, ktorá bude dodaná je už dostatočne preverená v inom podniku a že je jasné, ktoré časti IS bude pokrývať. Stačí teda definovať len rozdiely medzi požiadavkami podniku a možnosťami dodávaného už hotového riešenia a následne rozhodnúť ako zistené rozdiely budú riešené. V čiastkovom projekte Úvodná štúdiá je zmapovaná množina funkcií definujúcich daný komponent IS. Ďalej je analyzovaný súčasný stav pokrytia funkcií. Analýza sa zameriava v tomto prípade na zistenie stavu a prípravu implementácie už hotového riešenia. Teda ide o inak zameriavanú analýzu ako v prípade vytvárania vlastného na mieru ušitého riešenia. V tomto prípade ide o rozdelenie všetkých funkcií definujúcich daný komponent do troch skupín a to: o funkcie, ktoré budú pokryté bez nutnosti ďalších úprav, o funkcie, pre ktoré sú potrebné rôzne úpravy, o funkcie, ktoré dodávané riešenie obsahuje, ale nie sú požadované. Ďalej uvádzame príklad obsahu architektúry komponentu IS. 64

65 Architektúra komponentu IS 1. Funkcie o zoznam funkcií pokrývaných komponentom, o diagramy funkcií, o opisy funkcií, 2. Organizačná štruktúra podniku o opis existujúcej organizačnej štruktúry, o vymedzenie prvkov štruktúry dotknutých komponentom IS, 3. Opis existujúcej aplikácie pokrývajúcej komponent IS o opis funkcií a priradenie aplikácií zabezpečujúcich tieto funkcie, o opis aplikácií a ich hodnotenie, 4. HW a SW platforma o opis existujúcej HW platformy: servery a PC vrátane systémového prostredia, o opis SW platformy: aplikácie bežiace na serveroch a PC, bezpečnostné mechanizmy, o opis sieťového prostredia: typ kabeláže, aktívne prvky, protokoly, o administrácia systému, 5. Dátová architektúra o základný dátový model, 6. Špecifické požiadavky a návrh ich riešenia o hodnotenie prechodu na nový systém, o vymedzenie problémových oblastí a návrh postupu ich riešenia, o vymedzenie priorít. 65

66 Určenie postupov V čiastkovom projekte Určenie postupov vyplývajúcich z predchádzajúcej analýzy. je opísaný postup riešenia všetkých úloh Ide teda o riešenie problémov týkajúcich sa: o nasadenia typového riešenia komponentu, o väzieb komponentu k celému IS, o potrebných úprav typového riešenia. Všeobecne platí, že aj pred zavedením nového IS v rámci podniku existuje nejaký spôsob zabezpečovania procesu spracúvania informácií, ktorý sa dá vymedziť z hľadiska funkcií jednotlivých existujúcich časti doterajšieho IS. S tým súvisia aj pracovné postupy určitých ľudí a pracovné predpisy pre ich činnosť. Dá sa predpokladať, že nový IS môže zmeniť usporiadanie práce v podniku a teda bude doprevádzaný aj zmenami interných predpisov. Ďalej uvádzame rámcovú štruktúru obsahu tohto čiastkového projektu, ktorá môže byť s rôznymi modifikáciami reálne využívaná v praxi. Určenie postupov 1. Rámcový návrh postupu 2. Funkčný a procesný návrh projektu 3. Návrh dátovej základne 4. Návrh aplikačného softvéru 5. Návrh základného softvéru 6. Návrh hardvéru 7. Očakávaný dopad projektu na organizačnú štruktúru podniku 8. Personálne zdroje 9. Návrh spôsobu riadenia projektu 10. Návrh spôsobu prechodu na nové riešenie 11. Návrh sprievodných služieb 12. Projekčné služby 13. Konzultačné služby 66

67 Spôsob realizácie V čiastkovom projekte Spôsob realizácie je navrhnutý a podrobne opísaný spôsob realizácie projektu. V projekte je uvedený: o úplný zoznam krokov, ktoré je treba realizovať, o opis činností, ktoré je treba vykonať v rámci jednotlivých krokov, o určenie zodpovednosti za vykonanie krokov o a určenie termínov dokončenia krokov. V tomto projekte musí byť opísaný obsah nasledujúcich etáp: o o o o začatie, návrh realizácie, implementácia, skúšobná prevádzka. Ďalej uvádzame rámcové členenie tém pokrývaných týmto čiastkovým projektom. Spôsob realizácie 1. Harmonogram riešenia o Špecifikácia jednotlivých etáp riešenia, ich obsahu a termínov začatia/ukončenia o Nadväznosť etáp, vstupy a výstupy o Zodpovednosť za realizáciu etáp 2. Ekonomika projektu o Plánované náklady na budovanie IS o Plánované prevádzkové náklady nového IS o Plánované ekonomické prínosy projektu o Nevyhnuté predpoklady pre dosahovanie ekonomických prínosov 67

68 Etapa Začatie projektu Etapa sa zvyčajne skladá z týchto krokov: o formulovanie cieľov projektu, o definovanie organizačnej štruktúry projektu, menovanie funkcionárov o harmonogram realizácie čiastkového projektu, o pravidlá pre riadenie kvality, schválenie akceptačných testov, o kapacity a technické zabezpečenie, o rozpočet, o návrh zmluvy. Ako je uvedené etapa končí návrhom zmluvy o dodaní softvéru či licencie k softvéru. Prax ukázala, že je výhodné zmluvu koncipovať dvojstupňovo a to rámcovú zmluvu a vykonávacie zmluvy. Rámcová zmluva špecifikuje všetky všeobecné záležitosti bez ohľadu na detaily jednotlivých komponentov alebo modulov IS. Vykonávacie zmluvy špecifikujú len detaily čiastkových krokov. Sú stručné, pretože sa môžu odkazovať na rámcovú zmluvu Etapa Návrh realizácie Etapa sa zvyčajne skladá z týchto krokov: o riešiteľský a realizačný tím, o stručný opis súčasného stavu, o opis obehu dokladov, o určenie krokov implementácie, o systémové roly a prístupové práva, o príprava dát, o technológia prechodu do rutiny, o tlačové zostavy, o metodické opatrenia, o používateľská dokumentácia, o harmonogram prípravy používateľov, o základné míľniky implementácie, o odhad nákladov implementácie, o analýza úprav programov, o termíny realizácie úprav, o rozpočet etapy. Etapa končí prezentovaním návrhu realizácie, jeho schválením alebo určením požiadaviek na doplnenie. Taktiež môže skončiť odmietnutím predloženého projektu. 68

69 Vyvolané zmeny metodík musí byť schválené vedením podniku, pretože majú vplyv na interné normy Etapa Implementácia Kľúčovým znakom etapy je, že existujúce riešenie sa preklopí na nové riešenie a ľudia začnú pracovať s novým IS. Etapa sa zvyčajne skladá z týchto krokov: o o o o o o o o o o realizácia programových úprav vrátane dokumentácie a testovania, príprava používateľov systému a prístupových práv, vrátane zdieľaných číselníkov, identifikácia dát, ktoré budú získané konverziou existujúcej dátovej základne, spôsob doplnenia chýbajúcich dátových položiek pri začatí prevádzky IS, špecifikácia číselníkov vytvorených ručne v novom systéme, zoznam dát, ktoré, bude treba doplniť do IS počas prevádzky, migrácia dát, školenie koncových používateľov, príprava vzorky dát, overenie funkčnosti systému na vzorke dát Etapa Skúšobná prevádzka Táto etapa začína začatím rutinného používania implementovaných modulov nového IS za zvýšenej metodickej podpory používateľov zo strany riešiteľov. Etapa spravidla končí vyhodnotením cca 2 až 3 mesačnej skúšobnej prevádzky a protokolom o jej skončení. Je výhodné, ak pri takých veľkých projektoch ako sú nové podnikové IS sa skúšanie vykonáva najprv obmedzene, teda nie naraz v celom podniku. Zvyčajne sa vyberie vhodný závod alebo pobočka. Takémuto obmedzenému testovaniu sa niekedy hovorí aj pilótna prevádzka. Výhodou tohto postupu je, že celý podnik nie je dotknutý prípadnými problémami s prevádzkou nového systému a súčasne väčšina pracovníkov sa popri práci so starým systémom stretne aj s novým systémom. Dôležitým aspektom skúšania prevádzky nového IS je zabezpečenie paralelného chodu starého systému a overovanie vybraných výsledkov spracúvania, najmä rôznych výpočtov nového systému voči starému systému. 69

70 Personálne zabezpečenie projektu Realizačné tímy Základnou úlohou realizačných tímov je zabezpečiť realizáciu etapy projektu alebo jeho časti, ktorá tvorí samostatný logický celok. Je logické, že zloženie tímov zameraných na vytváranie dokumentácie projektu bude iné ako tímov určených na realizáciu napr. jednotlivých modulov. Ako príklad ďalej uvádzame zloženie dvoch tímov. Realizačný tím č. 1 - Úvodná štúdia o o o medzi jeho hlavné úlohy patrí najmä: o analýza súčasného stavy IS, o návrh postupov riešenia nového IS, o návrh spôsobu realizácie navrhovaného riešenia IS. vedúcim tímu je pracovník dodávateľa, členmi tímu sú tak pracovníci dodávateľa ako aj pracovníci odberateľa. Realizačný tím č. 2 až n o hlavnými úlohami pre jednotlivé tímy je implementácia jednotlivých modulov IS, o realizačný tím je zložený tak z pracovníkov dodávateľa, ako aj pracovníkov odberateľa. Ďalej uvádzame nasledovný: prehľad hlavných zodpovedností vedúceho tímu, ktorý môže byť o koordinácie práce realizačného tímu, o vypracovanie podkladov pre plán projektu, o posudzovanie a schvaľovanie výstupov členov tímu, o realizácia rozhodnutí RKP, o vedenie dokumentácie o činnosti tímu, o príprava a predkladanie správ o postupe prác na projekte, o návrhy na zmeny zloženia tímu, o návrhy motivácie členov tímu počas práce na projekte RKP RKP zabezpečuje tak koncepčné, ako aj operatívne riadenie projektu. To platí pre všetky etapy realizácie projektu. 70

71 Činnosti spadajúce pod koncepčné riadenie sú najmä tieto: o o o o o o o o o určenie hlavných cieľov a kritérií projektu, schválenie organizačnej štruktúry pre projekt, schválenie plánu a rozpočtu projektu, schvaľovanie dosahovania požadovaných výsledkov projektu, schvaľovanie motivácie pracovníkov pracujúcich na projekte, rozhodovanie o zásadných zmenách projektu, rozhodovanie o veciach presahujúcich kompetenciu vedúceho projektu za podnik a vedúceho projektu za dodávateľa, riešenie sporov nižších riadiacich vrstiev v rámci projektu, rozhodovanie o dôvernosti projektu alebo jeho častí a dokumentácie. Činnosti spadajúce pod operatívne riadenie sú najmä tieto: o o o o o o schvaľovanie plánu zdieľanej dokumentácie projektu, riadenie práce realizačných tímov a kontroluje postup a kvalitu projektu, schvaľovanie návrhov realizačných tímov schvaľovanie zloženia realizačných tímov navrhovanie zmien projektu príprava a predkladanie materiálov pre rokovanie RKP a vedenie podniku Dokumentácia riešenia a postupu prác Dokumentácia o priebehu realizácie projektu, ako aj dokumentácia vytváraného IS je dôležitá tak pre dodávateľa, ako aj odberateľa. Dokumentácia má vplyv na schopnosť vzájomnej komunikácia medzi nimi o rôznych stránkach realizovaného projektu. Od toho významu je možné priamo odvodiť požiadavky na vysokú kvalitu vytváranej dokumentácie a aj požiadavku na určitú štandardizáciu tak dokumentácie dokladujúcej priebeh projektu, ako aj dokumentácie dokladujúcej výsledok riešenie, teda nový IS. Je v záujme oboch strán aby sa využívala schválená evidencia všetkej dokumentácie projektu. Dokumentovanie projektu by tiež malo byť formalizované ako súčasť zmluvných podmienok. Vzájomne dohodnutý predpis/pravidlá o dokumentácii projektu IS spravidla obsahuje: o o vymedzenie dokumentácie projektu o zápisy z rokovaní, o rozhodnutia, o správy, o návrhy interných noriem, o zmenové požiadavky, o odovzdávacie protokoly, špecifikácia štandardnej úpravy dokumentov o úprava, o formát, 71

72 o o konvencia pre pomenovanie elektronických súborov, pravidlá pre vzájomné odovzdávanie dokumentov Zabezpečenie infraštruktúry Návrh infraštruktúry, v ktorej bude IS prevádzkovaný je súčasťou realizačného projektu. Skladá sa z návrhu požadovaného HW, SW, nutných úprav organizačnej štruktúry podniku, personálneho zaistenia prevádzky nového IS, prípadne ďalších oblastí. Infraštruktúra sa buduje pre dve úrovne a to: o o pre skúšobnú prevádzku, pre plný chod IS. Návrh infraštruktúry spravidla obsahuje: o opis softvéru ( OS severov a PC, prenosová sieť,...), o opis hardvéru ( servery, PC, tlačiarne, diskové polia, kabeláž, konektory,...), o zabezpečenie prevádzky HW a SW, o organizačné zmeny na strane používateľa, o nutné metodické zmeny, ktoré je treba premietnuť do interných noriem podniku. Dobrou otázkou je: Kto potom realizuje schválenú infraštruktúru nového IS? Všeobecne platí, že zabezpečiť potrebné komponenty môže tak systémový integrátor, ako aj samotný podnik. Ich osadenie na určených miestach a živenie taktiež môžu zabezpečovať tak pracovníci dodávateľa, ako aj zamestnanci podniku. Otázkou je len či podnik disponuje potrebnými špecialistami. Z vedeného vyplýva, že konkrétne riešenie vždy závisí od dohodnutých a zazmluvnených okolnosti spolupráce medzi podnikom a dodávateľom nového IS. Ak zabezpečenie komponentov infraštruktúry, ich osadenie a oživovanie zabezpečuje sám podnik využíva nato spravidla útvar IT a najmä týchto špecialistov: o o o o o o o správca serverov, správca lokálnej siete, správca PC, správca tlačiarní, databázový administrátor, metodik IS a správca centrálnych číselníkov, metodik modulu/komponentu IS. 72

73 Súčinnosť dodávateľa s podnikom Firma dodávateľa a podnik odberateľa nového IS majú svoje vnútropodnikové zvyklosti, ktoré je v prípade podpísania zmluvy o dodávke IS potrebné vzájomne zladiť, aby realizácia projektu bežala viac menej bez problémov. Nie je možné spoliehať na bežné zvyklosti. Napríklad pre dodávateľa môže byť problém viacstupňové rozhodovanie na strane podniku. Ďalej uvádzame zoznam oblastí spolupráce, ktoré by nemali byť podceňované zo stany dodávateľa ani zo strany podniku: o podpora vrcholového vedenia podniku, o spolupráca členov tímu a kľúčových osôb, o motivovanie riešiteľov, o kompetencie členov tímov, o kvalifikácia osôb, o kapacitné zabezpečenie projektu, o stabilita tímov, o logistika projektu, o dodržiavanie termínov, o adresnosť realizačných krokov, o dokumentovanie projektu, Súčinnosť s inými podnikmi Je výhodné, ak podnik budujúci nový IS spolupracuje s inými podnikmi budujúcimi podobný IS. Taktiež je výhodné využívať typové už praxou overené riešenia. Uvedené faktory môžu prinášať 15 % a ž 90 % úsporu nákladov, čo nie je zanedbateľné. Výhodou je aj možnosť spoločného financovania ďalšieho rozvoja využívaného systému Určenie typov používateľov nového IS a ich funkcií Všeobecne platí, že ak IS má pokryť všetky dôležité oblasti pôsobenia podniku, potom počet funkcií existujúcich v ňom mnohonásobne prevyšuje počet funkcií, ktoré môže reálne využívať jeden používateľ. Každý používateľ je totiž zaradený na konkrétne pracovné miesto a má priradené len určité prístupové práva, ktoré sa viažu k danému IS. Základné rozvrstvenie budúcich používateľov IS v podniku obsahuje Úvodná štúdiá. 73

74 V ďalšom období riešenia príslušný realizačný tím pripraví konkrétny návrh rozvrstvenia používateľov a ten je po schválení následne realizovaný v praxi. Pre správnu činnosť IS je dôležité, aby bolo možné priradiť jednotlivé funkcie systému určitému počtu používateľov a to vo väzbe na roly definované pre jeho prevádzku. V priebehu implementácie IS je preto potrebné určiť budúcu štruktúru koncových používateľov IS a zaradiť konkrétnych používateľov do tejto štruktúry. Pritom sa musí brať ohľad nato, ktoré funkcie je používateľ: o povinný používať, o oprávnený používať o a ktoré by mali byť pre neho nedostupné. Možných rolí definovaných pre prevádzku IS môže existovať niekoľko desiatok, možný počet pracovníkov podnikov sa môže pohybovať od niekoľkých desiatok až do niekoľkých tisícok. V praxi sa vyskytuje stav, keď jednej osobe sú priradené viaceré roly, čo súvisí s jeho pracovným zaradením alebo vykonávaním viacerých činnosti v rámci podniku. V takejto situácií je potrebné postrážiť nárast kompetencií u jedinej osoby, čo by mohol byť bezpečnostný problém. Je dobré, ak veľké podniky majú menovaných garantov pre vybrané vo veľkom počte sa vyskytujúce roly Školenie používateľov Dodávateľ nového IS zvyčajne pripravuje personál podniku na jeho používanie. Informovanie o novom IS sa v praxi vyskytuje v širokej palete aktivít a to od základných informačných brožúr či vystúpení dodávateľa na rôznych podnikových akciách, cez základné školenie o novom IS, až po detailné školenie určitých skupín používateľov. Školenie zamestnancov podniku spravidla prebieha dvojstupňovo. Najprv sú vyškolení vybraní ľudia - metodici pre danú oblasť. Následne sú vyškolení koncoví používatelia, ktorí budú nový IS používať pri svojej každodennej práci. Rozdiel medzi týmito školeniami okrem hĺbky nazerania na IS je aj prostredia pre nácvik. Metodici sú spravidla školení nad cvičnou databázou pripravenou dodávateľom, aby bolo možné prezentovať a odskúšať rôzne špecifické udalosti vyskytujúce sa pri prevádzke IS. Koncoví používatelia sú školení nad kópiou ostrej databázy. Špecificky problém predstavuje školenie vyšších manažérov podniku a doškoľovanie nových pracovníkov. 74

75 Častým nedostatkom školení je, že neobsahujú časti týkajúce sa bezpečnostných mechanizmov implementovaných do IS a do jeho prostredia, pritom ich zvládnutie zo strany používateľov je jednou z podmienok bezpečnej prevádzky IS. Záverom treba pripomenúť, že IS je živý organizmus, ktorý s neustále mení. V rytme s jeho zmenami by sa kontinuálnou školiacou činnosťou mali meniť aj poznatky a schopnosti jeho používateľov Vypracovanie interných noriem pre prevádzku IS a bezpečnostných noriem Typickým sprievodným znakom nových IS je potreba aktualizácie či úprav časti podnikovej predpisovej základne. Je maximálne nevhodné, aby používatelia boli vybavený neplatnými dokumentmi, ktoré sa týkajú už nepoužívaných verzií aplikácií IS, zatiaľ čo k poslednej práve využívanej verzií nemajú k dispozícií takmer nič. A to sa ešte v praxi nájdu ľudia, ktorí tvrdia, že nový systém možno používať podľa starej príručky, čo sa zvyčajne pri audite potvrdí tak na 20 až 40 %, čo je skutočne málo. Potom odpoveď na otázku: Ako sa bude posudzovať činnosť pracovníka pri vzniku bezpečnostného incidentu z hľadiska toho, či pracovník postupoval predpísaným spôsobom? nepoznajú a neuvedomujú si, že vlastne neexistuje etalón, voči ktorému je možné činnosť auditovať. To ale súčasne znamená, že pracovníka ani nie je možné postihovať. Preto pevnou súčasťou implementácie nového IS musí byť vypracovanie: o prevádzkových, o metodických o a bezpečnostných noriem pre prevádzku IS, predpisujúcich okrem iného chovanie používateľov pri využívaní IS. Bezpečnostné predpisy musia svojim obsahom vytvárať podmienky pre dobrú ochranu IS a spracúvaných dát. V podniku by mala existovať globálna bezpečnostná politika, ktorá je rozpracovaná do bezpečnostnej politiky pre informačnú bezpečnosť. Politika informačnej bezpečnosti musí nájsť svoju odozvu v bezpečnostnej politike sieťovej infraštruktúry a tá by mal byť rozpracovaná do bezpečnostnej politík jednotlivých aktívnych prvkov počítačovej siete využívanej podnikom. Bezpečnosť pripojenia do Internetu by mala byť samozrejmou súčasťou riešenia bezpečnosti každého IS. 75

76 Najdokonalejšou formou riešenia informačnej bezpečnosti v podniku je vybudovanie a certifikovanie ISMS podľa ISO/IEC Bezpečnostná dokumentácia prevádzkovaného IS je pritom povinnou súčasťou dokumentácie takéhoto firemného ISMS Postupné zavádzanie komponentov IS Skúsenosti z praxe dokazujú, že je výhodné moduloch či skupinách modulov. rozfázovať implementáciu nového IS po Pri zložitých IS je potrebné ešte rozfázovať aj zavádzanie modulov komponentu IS. Pokusy a zavedenie nového rozsiahleho IS naraz obvykle končia mnohými problémami. Základný postup pre zavedenie modulu IS má spravidla tieto kroky: o o o o o o o o upgrade VT súvisiaci s potrebami nového modulu, úpravy typového riešenia podľa požiadaviek podniku, skúšobná inštalácia, vstupné naplnenie modulu dátami, pripojenie iných modulov IS, testovanie modulu v skúšobnej prevádzke, akceptácia modulu, prevzatie do rutinnej prevádzky. Osobitným problémom je migrácia dát. Tá sa dá vykonať ručným vkladaným alebo automatickou konverziou dát zo starého IS do nového IS Monitorovanie priebehu implementácie Monitorovanie priebehu implementácie by malo prebiehať na všetkých úrovniach riadenia projektu. Implementačné tímy by sa schádzať pravidelne a vyhodnocovať pokrok alebo vznikajúce najmä časové a vecné odchýlky v riešení voči plánu projektu. Pre potrebu rýchleho riešenia problémov by s mali schádzať operatívne. Každé rokovanie by malo byť dokumentované záznamom. RKP musí taktiež sledovať postup prác, preto vedúci čiastkových projektov musia mať povinnosť pravidelne v písomnej alebo elektronickej forme informovať o stave svojho podprojektu. Súhrnnú správu za celý IS spracúva vedúci projektu za dodávateľa v spolupráci s vedúcim projektu za podnik a spoločne ju prekladajú na rokovanie RKP. Prípadne odsúhlasené zmeny sú na úrovni RK zaznamenávané do pôvodného plánu projektu. 76

77 Zistené informácie o stave projektu za projekt ako celok musia byť dostupné pre vedúcich riešiteľských tímov Testovanie Úvodom je nutné konštatovať, že sa testujú tak jednotlivé komponenty IS, ako aj celý systém. Testovanie prebieha tak u dodávateľa, ako aj u odberateľa. Špecificky problém predstavuje testovanie dátovej základne IS. Testovanie u dodávateľa Každá časť nového IS pred uvoľnením do používania prechádza testovaním u dodávateľa. Testovanie prebieha na základe definovaných testovacích procedúr a je vykonávané jednak samotnými tvorcami príslušných softvérov ( tzv. autorské testovanie) a zvláštnou skupinou zloženou s pracovníkov tak dodávateľa, ako aj odberateľa ( tzv. integračné testovanie). Testovanie odovzdávaných častí IS zabezpečujú pracovníci dodávateľa v súčinnosti s vybranými pracovníkmi podniku špeciálne pripravenými na túto činnosť. Testovanie v prvej fáze beží na vzorke dát pripravených dodávateľom, následne na vzorke dát pripravených zo strany podniku z ostrých dát. Testovanie spravidla prebieha na troch úrovniach a to: o testovanie modulov porovnávanie existujúcej funkčností dodaného softvéru so zadaním, o testovanie integračné v rámci modulu skúma sa najmä požadovaná súčinnosť modulov a správnosť odovzdávania dát, o testovanie integračné v rámci celého systému - skúma sa najmä požadovaná súčinnosť podsystémov IS a správnosť odovzdávania dát. Výsledky testov sú zaznamenávané do vopred pripravených protokolov, ktoré sú uložené v sídle dodávateľa. Pre funkčnosť IS je dôležitá konzistentnosť databázy jednotlivých modulov a celého systému. Tá sa preveruje vo viacerých krokoch a to najmä vo: o fáze prípravy implementácie kontrola úplnosti a konzistencie konvertovaných dát, o fáze vyhodnocovania skúšobnej prevádzky. 77

78 Akceptácia systému Na základe zadania pre vybudovanie nového IS, ktoré je zvyčajne súčasťou Úvodnej alebo Rozdielovej štúdie podnik sám pripraví akceptačné testy pre každý čiastkový projekt ešte v etape začatia projektu. Dôležité je, aby pri vytváraní scenáru akceptačných testov sa zobrali do úvahy aj návrhy dodávateľa IS. Akceptačné testy schváli RKP. Táto etapa sa v praxi často podceňuje. Faktom však je, že podpísaním protokolov o akceptácií otestovaných modulov IS končí možnosť priameho pokračovania úprav posudzovaných riešení na báze pôvodnej zmluvy. Neskôr objavené nedostatky a ich odstraňovanie vždy zápasia s problémami, najmä pri existencii nižšej dôvery medzi podnikom a dodávateľom IS. Proces akceptácie by mal byť medzi podnikom a dodávateľom formalizovaný a vzájomne zmluvne dohodnutý. Viac informácií o akceptačných testoch je uvedených v kapitole č Zmenové konanie Ku vzniku požiadavky na zmenu môže dôjsť kedykoľvek počas realizácie projektu. Realizácia zmien však nemá byť neriadená. Samotnému realizovaniu zmeny musí predchádzať nejaké posudzovanie požiadavky a schválenie príslušnými autorizovanými osobami. Zmenovým riadením sa všeobecne rozumie postup uplatnenia, posúdenia a riešenia zmeny obsahu, rozsahu, termínov, ceny a iných faktorov realizovaného projektu. Príkladom pravidiel pre zmenové riadenie môžu byť nasledovné pravidlá: o Požiadavku na zmenu môže podať ktokoľvek z riešiteľského tímu projektu písomne vedúcemu príslušného projektu. o Vedúci projektu zabezpečí jej posúdenie a na základe stanovísk odborníkov posúdi možnosť zaradenia zmeny na realizáciu. V odôvodnených prípadoch zmenu zamietne alebo vyžiada jej došpecifikovanie. o Ak požiadavka na zmenu je prijatá na úrovni vedúceho projektu, spracuje sa návrh realizácie vrátane dopadov na zmluvné vzťahy, cenu čiastkového projektu a termíny. Návrh sa predloží napríklad tajomníkovi RKP. o RKP doručený návrh na zmenu prerokuje, schváli alebo zamietne. Schválený návrh je odovzdaný vedúcemu projektu za dodávateľa na realizáciu o Vedúci projektu za dodávateľa IS zapracuje schválenú zmenu do plánu projektu. O realizovanej zmene informuje RKP. 78

79 Odovzdávanie modulov IS Potom, čo hotové časti nového IS boli akceptované zo strany podniku môže začať prebiehať ich odovzdávanie do rutinnej prevádzky. Tento krok je potrebné starostlivo zorganizovať. Postup odovzdávania by mal byť formalizovaný a obojstranne odsúhlasený ako súčasť zmluvných podmienok. Postup musí jednoznačne definovať postupnosť krokov vrátane návratu do predchádzajúcich stavov. Celý postup musí byť protokolovaný. Medzi základné pravidlá odovzdávania/ inštalovania časti IS na pracoviskách podniku patria: o odovzdávanie distribučnej verzie systému by malo prebiehať protokolárne a s dôkazom o jej funkčnosti, o inštaláciu zabezpečujú pracovníci dodávateľa za prítomnosti vybraných pracovníkov podniku, o o inštalácii každej časti IS je spísaný protokol, o do protokolu sa zapisujú aj prípadne problémy, ktoré sa vyskytli pri inštalácií a oživovaní jednotlivých častí softvéru. 79

80 4.2.8 Prevádzka, údržba a rozvoj IS Cieľom tejto časti skrípt je stručný opis prevádzky IS a ďalšieho rozvíjania úspešne implementovaného IS Pozícia podnikových útvarov pri prevádzke, údržbe a rozvoji IS Účasť podnikových útvarov na vytváraní a zavádzaní nového IS je rôzna. Určite najvýznamnejšiu úlohu má útvar IT, ktorý zrejme má k dispozícií aj najlepšie odborne pripravených zamestnancov pre tento účel. Budovanie nového IS sa taktiež nezaobíde bez činnosti niektorých celopodnikových útvarov ani bez spolupráce s nižšími organizačnými celkami ako sú závody či pobočky Útvar IT Všeobecne platí, že činnosť tohto útvaru má podstatný vplyv na úspešnosť IS tak z hľadiska prípravy a realizácie projektu zameraného na vybudovanie nového IS, ako aj na spokojnosť používateľov s novým IS. Aby útvar IT splnil svoje poslanie musí byť primerane vybavený tak špecialistami, ako aj kompetenciami v rámci celého podniku. Základné požiadavky na útvar IT môžu byť nasledovné: o o o o o o o o o o je to útvar s celopodnikovou pôsobnosťou, je podriadený členovi vrcholového vedenia podniku, má povinnosť navrhovať rozpočet pre prevádzky IS podniku, vo vzťahu k iným útvarom je aj servisným útvarom, poskytujúcim určité služby v oblasti IT, má v zodpovednosti spoluprácu s dodávateľmi systémov, systémovými integrátormi a servisnými spoločnosťami, má k dispozícií potrebných špecialistov alebo rozpočet umožňujúci zabezpečovať určité služby externe, zabezpečuje prevádzku celopodnikovej počítačovej siete, zabezpečuje prevádzku centrálnych serverov, zabezpečuje prevádzku IS podniku, organizuje celopodnikové školenia v oblasti IT Ďalšie podnikové útvary Okrem celopodnikového útvaru IT sa na príprave, realizácií a prevádzke IS podieľajú aj iné celopodnikové útvary. 80

81 Ide najmä o právny útvar, personálny útvar, investičný útvar, útvar nákupu a zásobovania, útvar dopravy ale aj metodické útvary. Právny útvar vstupuje do zmluvných vzťahov so systémovým integrátorom, dodávateľmi a inými subjektmi. Taktiež vstupuje do úprav a vydávania nových interných predpisov. Personálny útvar vstupuje do výberu vhodných pracovníkov, náboru nových potrebných špecialistov ale aj do prípravy rôznych celopodnikových školení. Zaobstarávanie komponentov investičnej povahy zaisťuje investičný útvar, zatiaľ čo nákup prostriedkov bežnej spotreby je v kompetencii útvaru nákupu a zásobovania. Pri rozmiestňovaní HW ale aj organizovaní potrebných presunov pracovníkov počas riešenia, skúšania a iných aktivitách súvisiacich s budovaním nového IS zohráva významnú úlohu útvar logistiky/dopravy. Každá odborná oblasť podnikania má svoje metodické zázemie. S novým IS často súvisia zmeny metodiky uplatňovanej v rámci určitých funkcií zabezpečovaných IS. Vytváranie nových metodík býva v kompetencií rôznych odborných, metodicky zameraných útvarov centrály podniku. Tieto a aj ďalšie útvary sa taktiež môžu zúčastňovať procesu vytvárania, posudzovania, schvaľovania a vydávania interných predpisov podniku, súvisiacich s novým IS Pracoviská závodov a pobočiek V podnikoch so zložitejšou organizačnou štruktúrou sa vyskytujú závody, pobočky či divízie, alebo iné typy často lokálnych pracovísk. Tieto organizačné útvary sa zúčastňujú podnikateľských aktivít a pri svoje práci vždy v nejakom rozsahu využívajú aj funkčnosť podnikového IS. Pracovníci týchto útvarov sú teda určitou skupinou budúcich používateľov nového IS. Funkčnosť dostupná na týchto organizačných útvaroch, osobitné požiadavky na vykonávanie určitých prác v určitej lokalite, ich úloha pri zálohovaní dát a vytváraní celopodnikovej databázy IS,... vyvoláva nutnosť prizývať vybraných pracovníkov závodov, pobočiek do vybraných riešiteľských tímov. Vedúci pracovníci týchto organizačných útvarov podniku sa zasa často stávajú členmi RKP Bezpečnosť IS a jeho prevádzky Z názvu kapitoly je zrejmé, že je potrebné zabezpečiť určité bezpečnostné vlastnosti samotného IS a ďalej je nutné zabezpečiť určité bezpečnostné pravidlá pre jeho prevádzku. Problematika je ďalej detailnejšie vysvetľovaná v ďalších kapitolách týchto skrípt. 81

82 Súčinnosť s dodávateľom po ukončení implementácie Odovzdaním nového IS do rutinnej prevádzky spolupráca so systémovým integrátorom nekončí. Spolupráca v tomto časovom období zvyčajne vychádza z predtým uzatvorenej rámcovej zmluvy, ktorá iste pamätala na podporu zo strany dodávateľa pri využívaní nového IS, ale aj na ďalšie aktivity. Spoluprácu s dodávateľom možno rozdeliť na tieto oblasti: o Reklamácie a nové požiadavky, o Ponuka úprav od dodávateľa, o Priebežná inovácia dodávateľom Reklamácie a nové požiadavky Vybavovanie reklamácií a iných požiadaviek by malo prebiehať podľa vopred schváleného Reklamačného poriadku, ktorý by mal byť súčasťou zmluvných podmienok. Ten by mal rozpracovávať jednotlivé praktické postupy. V praxi je v súčasnosti uprednostňovaný elektronický HELP DESK využívajúci , pred rozsiahlou papierovou agendou. Je zrejmé, že postup vybavovania reklamácie a požiadavky je iný. Postup pri ich vybavovaní možno špecifikovať takto: Reklamácia: Postupnosť krokov je nasledovná: určenie predmetu reklamácie, o lokalita, o príznaky, o okolnosti vzniku, uznanie reklamácie zo strany dodávateľa, o uznanie reklamácie, o rozhodnutie sporu podľa vopred dohodnutých pravidiel, realizácia reklamovanej opravy, testovanie opravy, akceptácia opravy, finančné vysporiadanie (napr. zaplatenie zmluvnej pokuty dodávateľom). Požiadavka: Postupnosť krokov je nasledovná: definovanie požiadavky, preverenie požiadavky z hľadiska zmysluplnosti a vykonateľnosti, určenie rozpočtu vykonania požiadavky, 82

83 určení termínov realizácie, schválenie termínov a rozpočtu dodávateľom, realizácia požiadavky, testovanie požiadavky, akceptácia spôsobu realizácie požiadavky, prevzatie hotového riešenia do rutinnej prevádzky, finančné vysporiadanie Ponuka úprav od dodávateľa Ponuka úprav od dodávateľa súvisí s využívaním typového riešenia, ktoré je nasadené u viacerých firiem a teda tvorca má ďalšie poznatky o možnom rozvoji IS podľa rôznych už realizovaných alebo vyslovených požiadaviek viacerých prevádzkovateľov. Vedúci útvaru IT by mal takéto ponuky preberať, posudzovať a v odôvodnených prípadoch predkladať ako námety vrcholovému vedeniu podniku. Je výhodné ak sa požiadavky podniku zahrnú do riešenia pre iného prevádzkovateľa, čím sa ušetrí čas a často aj peniaze Priebežná inovácia dodávateľom Inou formou spolupráce na ďalšom rozvoji IS je dlhodobý partnerský vzťah založený na časovo neobmedzenej zmluve o spolupráci pri rozvoji IS. Okrem iného to môže prinášať zníženie ceny riešenia a súčasne vzniká záruka dlhodobej angažovanosti tvorcu - dodávateľa pri riešení rôznych problémov a potrieb v ďalšom období. Pravidlom je, že dodávateľ vopred informuje podnik o pripravovaných zmenách a ich následkoch na prevádzku IS a používateľov. Záverom tejto častí skrípt je nutné konštatovať, že bola napísaná s využitím praktických poznatkov autora a súčasne s využitím inej literatúry ako časť skrípt týkajúca sa životného cyklu IS. Požiadavkou však je, aby výklad týchto tém bol nekonfliktný, vzájomne previazateľný. Na základe obsahu predchádzajúcich textov je k tomuto problému možné vykonať takéto zhrnutie: kapitola 3 obsahuje informácie o možných členeniach časového obdobia vzniku a využívania IS na menšie časové úseky s relatívne uzatvoreným obsahom nazývanými etapy alebo fázy životného cyklu, pritom sa neskúmajú detaily praktického zabezpečovania krokov vykonávaných v rámci fáz či etáp. kapitola 4 obsahuje informácie o praktickom postupe podniku budujúceho nový IS, pričom pripravuje a realizuje projekt zameraný na jeho vybudovanie. To dokresľuje obraz o širokej palete činností, ktoré sa v súvislosti s tým musia v praxi 83

84 realizovať. Kapitola súčasne špecifikuje nutnú angažovanosť podniku budujúceho nový IS a dodávateľa vytvárajúceho pre podnik tento IS. Etapy prípravy a realizácie projektu zameraného na vybudovanie nového IS v členení: Príprava projektu, Vypracovanie a schválenie projektu, Implementácia IS, Prevádzka, údržba a rozvoj, sú len iným usporiadaním tých istých krokov a časových úsekov (podriadených príprave a realizácii projektu) existujúcich počas životného cyklu IS vymedzovaných napríklad v takomto členení fáz životného cyklu IS: Plánovanie, Analýza systému, Návrh systému, Implementácia systému, Integrácia a testovanie systému, Akceptačné testovanie systému, Prevádzka a údržba systému. Ďalšie kapitoly skrípt opisujú väzbu medzi fázami životného cyklu IS a riešením bezpečnosti IS. Pre potreby výkladu sú využité poznatky uvedené v predchádzajúcich častiach textu, avšak viaceré poznatky sú účelovo upravené pre potreby jednoduchšieho výkladu riešenia bezpečnosti IS v rôznych časových intervaloch počas jeho životného cyklu. Podotýkame, že ďalšie kapitoly sú z hľadiska činností vykonávaných v rámci riešenia bezpečnosti IS neberú do úvahy spôsob realizácie IS, teda je jedno či podnik buduje sám nový IS alebo tento IS so objednal u nejakého dodávateľa. Taktiež neriešia otázky výberového konania na dodávateľa nového IS. 84

85 5 Plánovanie a manažment procesu budovania IS 5.1 Rámcový opis fázy Úlohou tejto fázy životného cyklu IS je určiť ciele budovania predmetného IS a vypracovať štúdiu vykonateľnosti, ktorá má obsahovať základné koncepčné riešenie IS z hľadiska finančných nárokov, technického zázemia a personálnych potrieb. Dôležitou súčasťou štúdie, okrem iných, je aj určenie vplyvu budovania nového IS na existujúcu bezpečnosť IS, už prevádzkovaných v spoločnosti. Súčasne úlohou tejto fázy je navrhnúť pravidlá pre riadenie činností všetkých zúčastnených strán s cieľom, aby IS vznikol a bol prevádzkovaný v riadenom prostredí. Významným výstupom tejto fázy životného cyklu IS je Plán budovania IS, prípadne plán budovania komponentu/podsystémy/modulu/inkrementu IS. V rámci tejto fázy životného cyklu IS sa takto definujú základné zásady a postupy pre riadenie realizácie procesu budovania IS. Fáza Plánovania a manažmentu začína ako prvá, prebieha v pozadí ďalších fáz a končí odovzdaním vybudovaného IS do rutinnej prevádzky. Poznamenávame, že táto časť skrípt vedome nerieši ani nekomentuje zaraďovanie budovania do rozvojového plánu podniku. Opis je formovaný za predpokladu, že budovanie IS bolo zaradené do príslušného plánu a bolo schválené príslušnými oprávnenými osobami. 5.2 Detailný opis fázy Detailný opis fázy vychádza z jednotlivých dokumentov, ktoré sú vypracovávané v rámci fázy a procedúr, ktoré majú byť realizované Inovačný zámer Je nesporné, že k začatiu procesu budovania IS nedochádza bezdôvodne. Obdobné platí aj pre akékoľvek zmeny už prevádzkovaných IS. Proces iniciovania úvah o budovaní nového IS alebo realizácie zmien v už prevádzkovaných IS je možné stotožniť s vypracovaním: Inovačného zámeru, Investičného zámeru ako písomného dokumentu. 85

86 Poznamenávame, že Inovačný zámer by mal vychádzať z Informačnej stratégie podniku spomínanej v kapitole 4 týchto skrípt. Posúdenie a schválenie IZ Možno povedať, že mala všeobecne by mala byť garantovaná možnosť pripraviť nejaký Inovačného zámer v spoločnosti bez zbytočných obmedzení. Praktickým problémom potom však je, ako posúdiť opodstatnenosť, závažnosť, či ekonomickú výhodnosť predložených Inovačných zámerov. Inovačný zámer pritom môže v sebe skrývať návrh budovania úplne nového IS, ako aj návrh na obnovu vybraných častí už prevádzkovaných technológií, či návrhy na rozšírenie modulov a funkčnosti prevádzkovaného systému. Na zvládnutie tohto problému musí v spoločnosti existovať jednak norma, ktorá určí záväzný obsah Inovačného zámeru, ako aj procedúra schvaľovania Inovačných zámerov. Platí, že len inovačné zámery, ktoré prešli schvaľovacou procedúrou s kladným hodnotením môžu byť posunuté do ďalšej prípravy Plánovanie procesu budovania IS Plánovanie procesu budovania IS vykonáva zadávateľ projektu, ktorý určuje aj ciele IS. V prípade nedostatočných skúseností s plánovaním procesu budovania IS sa odporúča prizvať k riešeniu špecializovanú konzultačnú firmu alebo sa podnik spoľahne na systémového integrátora. Výsledné dokumenty je možné podľa potreby podrobiť auditu nezávislou externou firmou. Plánovanie IS predpokladá uskutočnenie najmä nasledovných činností: určenie cieľov IS, vypracovanie štúdie IS, vypracovanie plánu budovania IS Určenie cieľov IS Pre určenie cieľov budovania IS sú k dispozícii viaceré metódy a postupy, ktoré sú bližšie opísané v dostupnej literatúre. Rozhodnutie o tom, ktorá metóda či postup bude použitá v praktických podmienkach, závisí najmä od charakteru, poslania a cieľov podniku/spoločnosti. 86

87 V minulosti a čiastočne aj v súčasnosti sa využíva jedna alebo kombinácia nasledovných metód: metóda funkčnej dekompozície, metóda kritických faktorov úspechu, metóda neurčite definovaných systémov, metóda alternatívnych scenárov. Plne využiteľným postupom pre určenie cieľov nového IS je aj využitie poznatkov z existujúcej Informačnej stratégie podniku, ktorá špecifikuje okrem iného aj možný budúci stav informačnej obsluhy podnikových agend informačnými systémami, pozri kap Vypracovanie štúdie IS Štúdia IS (Feasibility Study) je v poradí druhým dokumentom, ktorý vzniká v rámci životného cyklu IS. Rámcový obsah štúdie je možné vymedziť nasledovne: návrh koncepčného modelu IS; porovnanie navrhovaného riešenia s existujúcim stavom; návrh časového rozvrhu procesu budovania IS; určenie vývojových a dokumentačných prostriedkov; bezpečnosť, spoľahlivosť a výkonnosť IS; vplyv navrhovaného riešenia na existujúcu bezpečnosť prevádzky IT v spoločnosti ekonomické podmienky realizácie. Okrem určenia povinného obsahu štúdie IS, musí spoločnosť vytvoriť a schváliť aj procedúru schvaľovania vypracovaných štúdií. Z praxe sú známe rôzne postupy z hľadiska vypracovávania štúdií nového IS. Je vypracovaná buď: zjednodušená štúdia za celý IS, však z hľadiska informačného obsahu postačujúca pre rozhodovanie manažérov podniku, ktorá je podľa potreby ďalej rozpracovávaná v rámci štúdie, ktorá je súčasťou realizačného projektu komponentu IS, pozri kapitolu a , rozsiahlejšia a detailnejšia štúdia IS, rozpracúvajúca do potrebnej hĺbky aj jednotlivé podsystémy IS. Realizačné projekty jednotlivých podsystémov sa ňu odkazujú. Postup, ktorý bude použitý závisí len od podnikových zvyklostí. 87

88 Plán budovania IS Úvodom konštatujeme, že problematika určenia rozsahu projektu IS je mimo zamýšľaného obsahu tejto kapitoly. Teda predpokladá sa, že rozsah budovaného nového IS už bol určený, pozri kapitolu Platí, že až pre IS, ktorých štúdia kladne prešla schvaľovacím procesom, budovanie IS bolo zaradené do Rozvojového plánu podniku, ktorý bol schválený, je možné prikročiť k vypracovaniu Plánu budovania IS. Plán budovania IS obsahuje najmä vecný a časový harmonogram budovania IS spolu s predpokladanými finančnými výdavkami súvisiacimi s jednotlivými fázami životného cyklu IS, pozri kapitolu Dôležitou zložkou procesu plánovania IS je určenie nástrojov, ktoré budú použité pri vývoji IS. Ide najmä o prostriedky pre: analýzy a návrhu (CASE nástroje), vývoj SW (generátory kódov a programovacie prostredie), riadenie projektu (plánovacie systémy, workflow systémy,...), vytváranie a správu dokumentácie IS (textové editory, dokumentačné archívy), zabezpečenie kvality, zabezpečenie návrhu bezpečnostnej architektúry IS a ďalšie Riadenie projektu Integrálnou súčasťou tejto fázy životného cyklu IS je aj návrh systému riadenia procesu budovania IS. Manažment procesu budovania IS predstavuje samostatný problém, ktorý je potrebné vyriešiť pre každý IS. Keďže v praxi sa rozvoj IS rieši na báze realizácie rôznych projektov, je kvôli zjednodušeniu potrebné v ďalšom výklade a opise stotožniť pojmy riadenie procesu budovania IS a riadenie projektu alebo manažment procesu budovania IS a manažment projektu IS. 88

89 Cieľom definovania spôsobu riadenia projektu je zabezpečenie úplnej kontroly nad priebehom projektu zadávateľom projektu (podnikom objednávacím nový IS) od úrovne plánovania projektu, až po začatie rutinnej prevádzky IS a jej monitorovanie. Riadenie projektu možno definovať ako samostatný systém pozostávajúci z nasledovných komponentov: organizácia projektu, plánovanie, kontrola, motivácia. Pri definovaní systému riadenia projektu je potrebné zohľadniť špecifické charakteristiky konkrétneho IS. Organizácia projektu Organizácia procesu budovania IS, teda organizácia projektu, zachytáva vzťahy medzi jednotlivými účastníkmi. Organizácia projektu má v zásade 2 zložky: a) vonkajšia organizácia projektu, b) vnútorná organizácia projektu. Vonkajšia organizácia projektu definuje vzťahy medzi externými účastníkmi projektu, teda dodávateľskými subjektmi a organizačnými útvarmi podniku, ktorá buduje IS. Zvyčajne je reprezentovaná Riadiacou komisou/výborom, pozri kapitolu Vnútorná organizácia projektu vyjadruje vzťahy medzi jednotlivými riešiteľmi projektu na strane dodávateľa či realizátora IS. Všeobecne platná vnútorná organizácia projektu má nasledovnú štruktúru: vedúci (manažér) projektu; zástupca vedúceho projektu; vedúci podprojektov; jednotlivé realizačné tímy; zabezpečenie kvality; zaistenie bezpečnosti, výkonnosti a spoľahlivosti; správa dokumentácie a riadenie konfigurácií; sekretariát a administratívna podpora. Kontrola projektu Kontrola projektu predstavuje súbor postupov a procedúr, ktorými sa sleduje zhoda postupu prác a schválených plánov. 89

90 V rámci návrhu systému kontroly realizácie procesu budovania IS je potrebné určiť aj spôsob šírenia informácií o postupe prác medzi jednotlivými účastníkmi realizácie projektu, ako aj spôsob vyhodnocovania informácií. Je potrebné taktiež definovať formálne stretnutia, na ktorých prebieha koordinácia riešiteľských aktivít. S kontrolou úzko súvisí proces schvaľovania a preberania jednotlivých produktov (dokumentov, SW modulov, integrovaného systému, používateľskej dokumentácie, školení, atď.) V prípade nesplnenia kritérií prebratia, musí byť tvorca produktu zodpovedný za odstránenie identifikovaných nedostatkov a náhradné plnenie v určenom náhradnom termíne. Motivácia Súčasťou každého riadenia je aj motivačná zložka. V prípade využívania externého riešiteľa projektu zameraného na vybudovanie nového IS sa na strane podniku problém motivácie zužuje na motiváciu vlastných organizačných útvarov a zamestnancov pri plnení schváleného plánu budovania IS. Motivácia externého riešiteľa pre plnenie schváleného plánu projektu by mala byť vyriešená v rámci zmluvy o dielo, v časti cena a podmienky platenia dohodnutej ceny. Motivácia jednotlivých zamestnancov dodávateľa je výsostnou záležitosťou dodávateľa. Opísaný priebeh fázy plánovania a manažmentu procesu budovania IS je možné schematicky znázorniť diagramom postupu práce, ktorý prezentuje obrázok č Ako bolo uvedené skôr, fáza plánovania a manažmentu procesu budovania IS prebieha až do odovzdania IS do rutinnej prevádzky. Nutnou podmienkou pre efektívne plánovanie a riadenie procesu budovania nového IS je zber spätných informácií o priebehu a stave realizácie ďalších fáz životného cyklu IS, čo je znázornené obrázkom č Riešenie bezpečnosti IS Zaistenie bezpečnosti IS počas životného cyklu vyžaduje, aby v rámci fázy Plánovania a riadenia : a) tvorca Inovačného zámeru špecifikoval aj zámer z hľadiska bezpečnosti predmetného IS, ak je to možné; b) tvorca Štúdie IS špecifikoval aj možné varianty zaisťovania bezpečnosti predmetného IS, ak je to možné; c) tvorca Plánu budovania IS naplánoval procesy, ktoré budú realizované v súvislosti s riešením bezpečnosti IS. Splnenie tejto požiadavky sa nezaobíde bez spolupráce s budúcim prevádzkovateľom IS a bezpečnostným manažérom predmetného IS. 90

91 Obrázok č Priebeh fázy plánovania a manažmentu procesu budovania IS Z Prekladanie inovačných zámerov IZ nie Sú preložené nejaké IZ IZ Stratégia rozvoja spoločnosti Posúdenie IZ a schválenie stanoviská nie IZ bol schválený? Protokol o schválení Vypracovanie š túdie IS Štúdia IS Posúdenie a schválenie štúdie IS stanoviská nie Štúdia bola schválená? Protokol o schválení Vyprac ovanie plánu budo vania IS Plán budovania IS Posúdenie a schválenie plánu stanoviská nie Plán bol schválený? Protokol o schválení Návrh s ys tému riadenia proces u budovania IS Posúdenie a chválenie systému riadenia Návrh systémy riadenia stanoviská nie Plán bol schválený? K Protokol o schválení 91

92 Obrázok č Zber spätných informácií pre potrebu plánovania a riadenia projektu IS SPRÁVY O STAVE RIEŠENIA SPRÁVY O STAVE RIEŠENIA VÝVOJ SW PLÁNOVANIE A RIADENIE ANALÝZA IS PROJEKTOVANIE IS INTEGRÁCIA A TESTOVANIE IS AKCEPTAČNÉ TESTOVANIE PREVÁDZKA A ÚDRŽBA IS SPRÁVY O STAVE RIEŠENIA SPRÁVY O STAVE RIEŠENIA BUDOVANIE HW A ZÁKLADNEHO SW SPRÁVY O STAVE RIEŠENIA SPRÁVY O STAVE RIEŠENIA SPRÁVY O STAVE RIEŠENIA SPRÁVY O STAVE RIEŠENIA 92

93 5.3 Dokumenty vznikajúce v rámci fázy V rámci fázy Plánovanie a manažment životného cyklu IS budú vznikať nasledovné dokumenty : 1. Inovačný zámer, 2. Stanovisko z posúdeniu IZ, 3. Súhrnné stanovisko posúdenia IZ, 4. Protokol zo schvaľovania IZ, 5. Štúdia IS, 6. Stanovisko z posúdenia Štúdie IS, 7. Protokol zo schvaľovania Štúdie IS, 8. Plán budovania IS, 9. Stanovisko z posudzovania Plánu budovania IS, 10. Protokol zo schvaľovania Plánu budovania IS, 11. Návrh systému riadenia procesu budovania IS, 12. Stanovisko z posudzovania návrhu systému riadenia, 13. Protokol zo schvaľovania systému riadenia procesu budovania IS. 5.4 Metódy určenia cieľov budovania IS Metóda funkčnej dekompozície Metóda funkčnej dekompozície je metódou vhodnou pre analýzu informačných požiadaviek tých funkcií v rámci spoločnosti, ktoré zabezpečujú výkon dobre známych, štandardných a opakovaných činností. Jej uplatnenie je založené na dekompozícii činnosti spoločnosti na skupiny činností nazývaných funkcie, ktoré sa zoskupujú do funkčných oblastí. Funkcie sa ďalej delia na procesy, ktoré na rozdiel od funkcií, ktoré majú pokračujúci charakter, sa vzťahujú na nejaký akt, ktorý má definovateľný počiatočný a koncový bod a identifikovateľné vstupy a výstupy. Na úrovni plánovania procesu budovania IS sa pracuje s funkčnými oblasťami a významnými procesmi. Funkčné oblasti sa pritom odvodzujú z cieľov spoločnosti a predmetu podnikania. V etape analýzy a návrhu jednotlivých aplikačných modulov systému sa navrhovatelia zaoberajú jednotlivými procesmi a ich zabezpečovaním prostredníctvom procedúr. Dekompozíciu funkčných oblastí na funkcie a procesy možno vykonať nezávisle na organizačnej štruktúre spoločnosti. Pre znázornenie väzieb medzi funkciami a organizačnou štruktúrou spoločnosti sa využíva matica väzieb. V ďalšom kroku analýzy informačných potrieb je potrebné definovať potrebné dáta na úrovní typov entít pre výkon jednotlivých funkcií a procesov. 93

94 Vzťah medzi funkciami a dátovými entitami sa taktiež vyjadruje pomocou matíc. Pre vypracovanie funkčných a dátových modelov IS sa používajú grafické prostriedky CASE. Výsledkom funkčnej dekompozície IS teda sú : Identifikácia funkčných oblastí a funkcií; Matica väzieb funkčných oblastí a funkcií na organizačnú štruktúru spoločnosti; Definovanie požiadaviek na dáta na úrovni dátových entít; Matica požiadaviek funkcií na dáta. Obrázok č. 5-3 znázorňuje v zjednodušenej forme postup prác pri uplatnení metódy funkčnej dekompozície pre určenie cieľov IS. 94

95 Obrázk č Postup prác pri uplatnení metódy funkčnej dekompozície pre určenie cieľov IS Z Dekompozícia činnosti spoločnosti Funkčné oblasti a funkcie Vytvorenie matice väzieb funkčných oblastí s organizčnou štruktúrou spoločnosti Matica väzieb Definovanie dát pre výkon funkcií a procesov Dáta Vytvorenie matice požiadaviek funkcií na dáta Štúdia IS áno Sú potrebné zmeny vo funkčnej dekompozícií? K 95

96 5.4.2 Metóda kritických faktorov úspechu Metóda kritických faktorov úspechu je vhodná pre zistenie informačných požiadaviek funkcií, ktoré sú pre spoločnosť rozhodujúce z hľadiska dosiahnutia jej obchodných cieľov. Kritické faktory úspechu spoločnosti sú tie oblasti činnosti spoločnosti, ktoré vyžadujú trvalú a systematickú pozornosť zo strany vedenia spoločnosti. Počet kritických faktorov úspechu spoločnosti nie je obvykle veľký. Kritické faktory úspechu sú v rámci spoločnosti odlišné pre každého vedúceho pracovníka. Preto sa táto metóda orientuje na analýzu informačných požiadaviek jednotlivých vedúcich pracovníkov spoločnosti. Súhrnne by počet kritických faktorov úspechu nemal za spoločnosť prekročiť počet 10. Prehľad o kritických faktoroch úspechu jednotlivých vedúcich spoločnosti sa získava prostredníctvom interview. Informácie týkajúce sa kritických faktorov úspechu môžu byť buď presné údaje (hard data) alebo odhady / subjektívne názory (soft data). Mnohé kritické faktory úspechu budú vyžadovať externé informácie, pre ktoré je potrebné zmapovať zdroje. Ďalšie kritické faktory úspechu môžu vyžadovať koordináciu alebo integráciu dát z viacerých interných systémov spoločnosti a povedú k vytvoreniu banky dát. Kritické faktory úspechu sa obvykle definujú vo väzbe na určité predpoklady, ktoré sa musia splniť. Nazývajú sa kritické predpoklady a je pre ne charakteristické, že sa menia v čase. Preto je potrebné sledovať a analyzovať ich vývoj, čo rezultuje do ďalších informačných potrieb. Ďalší vplyv na vymedzenie kritických faktorov úspechu majú určité rozhodnutia spoločnosti. Súčasťou identifikácie kritických faktorov úspechu je potom aj identifikácia množiny kritických rozhodnutí. Množina informácií nevyhnutných pre identifikáciu kritických faktorov úspechu, kritických predpokladov, kritických rozhodnutí predstavuje množinu kritických informácií. Postup zistenia kritických faktorov úspechu spoločnosti možno vymedziť nasledovnou postupnosťou krokov : príprava tímu, úvodné usmernenie činnosti tímu (workshop), príprava jednotlivých interview, realizácia interview, spracovanie výsledkov a vyhodnotenie získaných poznatkov, využitie výsledkov analýzy. Proces analýzy kritických faktorov úspechu spoločnosti je možné schematicky znázorniť diagramom postupu činností, ktorý predstavuje obrázok č

97 Obrázk č Postup prác pri uplatnení metódy analýzy kritických faktorov úspechu pre určenie cieľov IS Z Zistenie kritických faktorov úspechu Kritické faktory úspechu Zistenie kritických predpokladov Kritické predpoklady Zistenie kritických rozhodnutí Kritické rozhodnutia Definovanie zoznamu kritických informácií Zoznam kritických informácií áno Je potrebné prehodnotiť poznatky? K 97

98 Výsledkom uplatnenia metódy kritických faktorov úspechu je nasledovná dokumentácia: Zoznam kritických faktorov úspechu; Zoznam kritických predpokladov; Zoznam kritických rozhodnutí; Zoznam kritických informácií. V závislosti od zmien prostredia, v ktorom spoločnosť pôsobí, ako aj od zmien cieľov spoločnosti dochádza ku zmene kritických faktorov úspechu. Preto je potrebné ich primerane revidovať. Je vhodné, aby údaje súvisiace s uplatnením tejto metódy boli uložené v databázach systému CASE, pretože to vytvára dobré podmienky pre ich následnú aktualizáciu v závislosti od získaných nových poznatkov Metóda činnosti SSM- Soft Systems Methodology Metóda vytvárania modelov činnosti SSM je určená pre analýzu zložitých systémov s nejasnými a neštandardnými problémovými situáciami. Metóda bola vyvinutá na báze systémového inžinierstva a je určená pre prípady, kedy je potrebné nielen rozhodnúť ako problém vyriešiť, ale aj čo je treba urobiť. Analýza metódou SSM sa uskutočňuje v nasledovných krokoch : voľné zobrazenie problému ( rich picture), základná definícia ( root definition), model činnosti (activity model), vypracovanie zoznamu informačných požiadaviek. Zoznam definovaných informačných požiadaviek sa využíva ako východisko pre zostavenie dátového modelu spoločnosti a budúceho IS Metóda alternatívnych budúcich scenárov Metóda alternatívnych budúcich scenárov je určená pre prípady, keď informačné požiadavky spoločnosti sú veľmi premenlivé. Potom nie je možné uplatniť budovanie štandardných aplikácii, ale naopak je potrebné budovať tzv. flexibilnú informačnú architektúru. Alternatívne scenáre umožňujú identifikovať rôzne alternatívy cieľov spoločnosti a z toho vyplývajúce rôzne alternatívy informačných potrieb spoločnosti. V zásade pre každú alternatívu cieľov spoločnosti je potrebné metodikou SSM vytvoriť model činností a definovať požiadavky na informácie a toky informácií. Flexibilná informačná architektúra vzniká prienikom informačných požiadaviek všetkých alternatív cieľov spoločnosti. Znamená to, že určité časti všetkých alternatív informačných potrieb spoločnosti sú spoločné a tie by sa mali stať základom budovania flexibilnej informačnej architektúry spoločnosti. 98

99 Ďalší rozvoj takto vybudovanej informačnej základne je smerovaný do vytvárania IS pre prienik informačných potrieb niekoľkých existujúcich alternatív. Prakticky to znamená, že ako bol vyriešený problém informačného zabezpečenie 3 existujúcich alternatív informačných potrieb spoločnosti, pristúpi sa k riešeniu informačných potrieb prienikov dvojíc alternatív informačných potrieb spoločnosti. Významným faktorom úspechu je správne rozhodnutie vedenia spoločnosti o prioritách v postupe budovania IS pre pokrytie nižších druhov prienikov informačných potrieb. 5.5 Vypracovanie koncepčného modelu IS Vypracovanie koncepčného modelu IS v sebe zahŕňa : vytvorenie dátového modelu vysokej úrovne, návrh štruktúry IS, návrh technického riešenia IS Dátový model vysokej úrovne Pre vytvorenie dátového modelu vysokej úrovne sa využívajú tzv. entitno-relačné diagramy. V rámci týchto diagramov sa využíva určité zjednodušenie a zovšeobecnenie riešeného problému. Zvyčajne sa upúšťa od vyjadrenia kardinality a definovania atribútov typov entít. Dátový model vysokej úrovne obsahuje len dáta, ktoré sú : strategicky dôležité pre spoločnosť, teda ovplyvňujú jej hlavné činnosti; slúžia k definovaniu integračných potrieb; potrebné ako prostriedok pre orientáciu vo väčších a zložitejších dátových modeloch. Pre tvorbu dátových modelov vysokej úrovne sa odporúča ako hraničný počet pre bežný IS, 50 dátových entít a pre veľmi zložité IS do 100 dátových entít. Východiskom pre vytvorenie dátového modelu vysokej úrovne je špecifikácia informačných požiadaviek vytvorená niektorou z metód opísaných v rámci týchto skrípt. Aby sa dátové modely rozsiahlych IS dali ľahko udržiavať a boli zrozumiteľné, stabilné a poskytli potrebnú úroveň podrobnosti pre plánovanie a projektovanie IS, bola vyvinutá technika zoskupovania modelov entít, tzv. entity model clustering. Kompletný výsledný dátový model IS je hierarchiou stále podrobnejších ER - diagramov. Sú odporúčané 3 úrovne dátových modelov, a to : model vysokej úrovne, dekompozícia modelu vysokej úrovne do modelov predmetných oblastí, dekompozícia modelov predmetných oblastí do modelov informačných oblastí. 99

100 V každej spoločnosti existujú dátové entity, ktoré sa vyskytujú vo viacerých oblastiach činnosti. Takéto dátové entity sa nazývajú hlavné typy dátových entít. Dátový model vysokej úrovne vlastne tvoria všetky hlavné typy dátových entít a ich relácie Návrh štruktúry IS Návrh štruktúry IS sa vypracováva na základe výsledkov analýzy cieľov budovania IS. Z nej okrem iného vyplývajú poznatky o : účele spracovávania informácií a z toho vyplývajúcich typov aplikácii; oblasti činnosti spoločnosti, ktorá bude automatizovaná budovaným IS; úrovniach riadenia spoločnosti, ktoré bude IS podporovať; väzbách IS na organizačnú štruktúru spoločnosti; väzbách IS na priestorové rozloženie spoločnosti; vplyvoch externého prostredia, v ktorom spoločnosť pôsobí na IS a ďalšie. Vytvorenie návrhu štruktúry IS vyžaduje jeho rozdelenie na relatívne samostatné časti nazývané subsystémy (moduly), a to podľa povahy činnosti. S týmito relatívne samostatnými časťami IS potom súvisia skupiny funkcií a entity dát. V rozsiahlejších spoločnostiach môže vzniknúť potreba vytvoriť pre každú organizačnú zložku (ústredie, pobočka, regionálne pracovisko,..) relatívne samostatný IS s dobre definovanými vzájomnými väzbami. V rámci celej spoločnosti je potom potrebné uplatniť dôslednú štandardizáciu dát, procedúr a programov. Priestorové rozloženie spoločnosti ovplyvňuje najmä technické riešenie IS (umiestnenie HW, rozloženie sietí pre prenos dát,...) a priradenie jednotlivých aplikácií k hardvéru (centrálny výpočtový systém, servery sietí, PC pracoviská,...). Komunikácia spoločnosti s existujúcim prostredím vynucuje uplatniť pri návrhu štruktúry IS rôzne externé štandardy, definície dátových a komunikačných rozhraní, ako aj definovať spracovateľské aplikácie vyvolané informačnými potrebami spoločnosti pri komunikácii s partnerskými spoločnosťami a orgánmi štátu Návrh technického riešenia IS Návrh technického riešenia IS v sebe zahŕňa rozhodovanie o druhoch a typoch techniky, ktoré budú tvoriť HW platformu budovaného IS, vrátane požadovaných parametrov pre jednotlivé druhy VT, riešenie problémov HW a SW kompatibility v celom IS, riešenie topológie interných počítačových sietí a komunikačných rozhraní s vonkajšími sieťami, riešenie základných prvkov bezpečnostnej architektúry IS až po výber OS, DB prostredia a vývojového prostredia pre centrálny a záložný výpočtový systém, servery sietí a PC pracoviská. Vytvorené návrhy sú ďalej rozpracovávané vo fáze budovania HW platformy IS, keď sa presne určia dodávatelia, ako aj detailné parametre jednotlivých komponentov. 100

101 Súčasťou návrhu technického riešenia IS je aj rozhodovanie a uplatnení komerčného aplikačného balíka alebo o vývoji vlastného, na mieru ušitého SW balíka prestavujúceho SW časť budovaného IS. 5.6 Podmienky začatia a ukončenia fázy Fáza plánovania a riadenia realizácie IS je zahájená schválením predmetného IZ. Plánovanie realizácie IS je ukončené schválením Plánu budovania IS a systému riadenia realizácie IS. Riadenie realizácie IS prebieha počas celej životnosti predmetného IS. 5.7 Zodpovednosť za realizáciu fázy Fázu Plánovanie a riadenie realizácie IS zabezpečuje útvar spoločnosti, ktorý má organizačným poriadkom delegované činností súvisiace s projektovaním IS. V praxi môže nastať odklon v zabezpečovaní tejto fázy životného cyklu IS, pretože dôjde k rozhodnutiu o uplatnení externých riešiteľských kapacít. Za takejto situácie útvar spoločnosti zodpovedá za celkovú koordináciu priebehu fázy a za jej uskutočnenie pri dodržaní smernice platnej v spoločnosti. 101

102 6 Analýza IS 6.1 Rámcový opis fázy Táto časť skrípt je spracovaná s cieľom opísať vytvorenie modelu budúceho IS za predpokladu, že sa nepoužije typové riešenie. Tým sa dopĺňajú informácie uvedené v 4. kapitole skrípt, ktorá je prioritne zameraná na opis okolnosti, keď sa rozhodlo o využití externého dodávateľa a typového riešenia IS. Vo Fáze Analýza IS životného cyklu IS sa analytickou činnosťou dodávateľa vykonáva identifikácia neformálnych požiadaviek používateľov podnikového IS na informácie z IS, spôsob ich spracovávania, ich štrukturalizácia a spracovanie do komplexného popisu týchto požiadaviek v tvare modelu. Pod používateľskými požiadavkami sa pritom rozumejú všetky požiadavky, ktoré definuje podnik (zadávateľ, používateľ a/alebo prevádzkovateľ IS), pozri kapitolu Vytvorený model požiadaviek používateľov IS, schválený podnikom, slúži ako zadanie pre vývoj programov, ktoré budú tvoriť aplikačný SW budovaného IS. Keďže dodávateľ v tejto fáze vytvára aj predstavu o chovaní s IS voči používateľom je potrebné vytvoriť nejaký prostriedok pre overenie, či zamýšľané chovanie bude také, ako je zo strany budúcich používateľov požadované. S tým súvisí akceptačné testovanie. Ďalšími činnosťami spadajúcimi do tejto fázy sú: vypracovanie plánu kvality IS vypracovanie plánu validácie IS. Obidva plány vytvára dodávateľ. Plán kvality pôsobí dovnútra spoločnosti dodávateľa IS a je využívaný na kontrolovanie dosahovania kvality IS realizačnými tímami. Plán validácie sa využíva medzi dodávateľom a odberateľom. Obsahuje pravidlá a mechanizmy dohodnuté najmä na overovanie riešení a výsledkov či výstupov dodávateľa zo strany odberateľa IS, teda podniku budujúceho nový IS. Významné kroky sa vykonávajú aj v rámci riešenia bezpečnosti IS. 102

103 6.2 Detailný opis fázy Etapy realizácie fázy Fáza Analýza IS sa skladá z nasledujúcich etáp: Analýza požiadaviek používateľov IS; Špecifikácia nového IS; Technická špecifikácia nového IS; Vypracovanie, posúdenie a schválenie Analytického projektu IS; Vypracovanie a schválenie Plánu akceptačného testovania IS; Vypracovanie a schválenie Plánu kvality IS; Vypracovanie a schválenie Plánu validácie IS Vypracovanie a schválenie Riešenia bezpečnosti IS Analýza požiadaviek používateľov IS V etape analýzy požiadaviek používateľov IS sa zisťuje súčasný stav v spoločnosti z hľadiska činností súvisiacich s vytváraným IS a z hľadiska informačných požiadaviek na pripravovaný IS. Pri identifikácii používateľských požiadaviek sa vychádza z cieľov IS definovaných v etape plánovania procesu budovania IS. Zvyčajne sa začína analýzou už prevádzkovaného IS, identifikáciou jeho nedostatkov, ďalších vzniknutých požiadaviek alebo navrhovaných vylepšení. Z hľadiska rozpoznávania používateľských požiadaviek je vhodné postupovať systematicky a požiadavky rozčleniť do niekoľkých kategórií, a to : funkčné požiadavky, kvalitatívne požiadavky, požiadavky vyplývajúce z kritických vlastností, identifikácia zdrojov. Funkčné požiadavky definujú požadované funkcie budúceho IS. Kvalitatívne požiadavky určujú vlastnosti budúceho IS z hľadiska určitých charakteristík. Kvalitatívne požiadavky sa v zásade delia na požiadavky vyplývajúce z funkcií systému a kritických vlastností systému. Požiadavky vyplývajúce z funkcií systému sa ďalej členia na : používateľský komfort, modifikovateľnosť, spoľahlivosť, Iné. 103

104 Požiadavky vyplývajúce z kritických vlastnosti IS sa ďalej členia na : kontrolné mechanizmy implementované v IS, riadenie prístupu do IS, požadované bezpečnostné vlastnosti IS, iné Model budúceho IS Na základe požiadaviek identifikovaných dodávateľom IS analýzou podkladov a prostredia podniku - budúceho používateľa IS, sa vytvorí model budúceho IS, v ktorom sa modeluje požadované spracovávanie informácií. Model budovaného IS umožňuje vymedziť predpokladaný spôsob spracovávania informácií, ktoré bude vyhovovať požiadavkám kladeným na budovaný IS zo strany objednávateľa. Model by mal zachytiť nasledovné informácie : rozhranie IS s okolím; funkčné špecifikácie, opis funkcií a ich väzieb, ktoré má IS vykonávať; dátové špecifikácie, opis štruktúry a vzájomných vzťahov spracovávaných dát; špecifikácie používateľských interfejsov, spôsob komunikácie IS s používateľmi najmä prostredníctvom obrazovkových vstupov a výstupov; špecifikácie dávkových interfejsov, najmä spôsob komunikácie s inými IS; špecifikácie riadenia, opis prípustnej logickej postupnosti operácii v budovanom IS. Je vhodné, avšak nepovinné, vytvoriť model budúceho IS pomocou špeciálnych grafických jazykov. Taktiež je možné, avšak nepovinné, navrhnúť na schematickej úrovni viacero alternatív riešenia informačných požiadaviek používateľov budúceho IS (napr. uplatnením metódy SSADM). V prípade vypracovania alternatív sa predpokladá aj určenie rizík spojených s ich realizáciou, ako aj návrh doporučenej alternatívy spolu so zdôvodnením. Rozhodnutie o výbere alternatívy, ktorá sa ďalej rozpracováva sa spolu so zdôvodnením archivuje Špecifikácia IS V etape špecifikácie IS sa vytvárajú tzv. logické modely požadovaného IS. Tieto modely sa vytvárajú špeciálnymi grafickými jazykmi. 104

105 Modely IS logickej úrovne sú nezávislé na HW a základných SW prostriedkoch, ktoré budú tvoriť v budúcnosti HW a základnú SW platformu IS, ako aj od organizačnej štruktúry spoločnosti a jej priestorového rozloženia Technická špecifikácia IS V etape vytvárania technickej špecifikácie IS sa na základe poznatkov z predchádzajúcich etáp definujú technické požiadavky na hardvér ( typ počítača, konfigurácia,...) a na základný softvér (typ DB prostredia, jeho konfiguráciu, sieťový softvér, softvér pre PC,...). Základné požiadavky na HW a SW sa spoločne nazývajú aplikačná architektúra IS. Pre túto etapu nie je predpísaná žiadna metodika alebo špeciálny vyjadrovací jazyk. Obvyklým javom v praxi je, že zadávateľ IS zvyčajne nie je tvorcom softvérového riešenia IS, vybudovanie celého IS, vrátane HW platformy ponecháva na tzv. systémového integrátora IS. Systémový integrátor je zvyčajne potom zodpovedný za metodiku vykonávania činnosti v rámci tejto fázy. Metodika súvisí s uplatnením konkrétnych metód v rámci jednotlivých etáp fázy Opis vybraných metód vhodných pre uplatnenie v rámci analýzy IS Ďalej uvádzame stručný opis vybraných metód vhodných pre uplatnenie v rámci analýzy IS. SSADM Podľa tejto metodiky sa modeluje súčasné fungovanie spoločnosti a vytvorený model sa využíva na vytvorenie modelu požadovaného systému. V etape analýzy požiadaviek používateľov na budúci IS sa vytvára diagram dátových tokov, reprezentujúci tok dokumentov v danej spoločnosti. V etape špecifikácie požiadaviek na budúci IS sa s využitím diagramu dátových tokov kopírujúceho skutočnosť, ktorá reálne existuje v spoločnosti, vytvára diagram dátových tokov požadovaného systému. SA/SD Podľa tejto metodiky sa vytvára model požadovaného IS. V etape analýzy požiadaviek sa nevytvárajú žiadne modely. V etape špecifikácie požiadaviek sa napíše zoznam udalostí, na ktoré je treba reagovať. Pre každú udalosť sa vytvorí samostatný proces v počiatočnom diagrame dátových tokov. Takýto diagram sa ďalej zovšeobecňuje, reorganizuje a špecializuje. Od riešiteľa IS sa požaduje dodanie predpísaných výstupov potrebnej kvality v dohodnutých termínoch. Uvedené súvisí so sledovaním priebehu procesu budovania IS a kontroly dodržiavania platného harmonogramu riešenia IS. 105

106 Poznatky získané analytickou činnosťou v prvých etapách v rámci fázy Analýza IS sú sústreďované v etape tvorby analytického projektu do písaného dokumentu, ktorý sa nazýva v praxi často nazýva Analytický projekt IS. Tento projekt je súčasťou celkového realizačného projektu IS. Špecifické vyjadrovacie jazyky V rámci fázy - Analýza IS sa využívajú CASE systémy a rôzne textové editory. Na vyjadrenie výsledkov analytickej činnosti sa z časti povinne a z časti nepovinne používajú špeciálne grafické jazyky. V rámci definovania špecifikácie požiadaviek používateľov na budúci IS sa povinne používajú nasledovné textové časti : Činnosť Vyjadrenie - Zoznam požiadaviek používateľov - v tvare prirodzeného jazyka s uvedením žiadateľa a priority - Špecifikácia elementárnych procesov - v tvare prirodzeného jazyka - Špecifikácia dátovej entity - zoznam atribútov s ich typmi - Špecifikácia obrazovkového vstupu/výstupu - štruktúra V/V z metódy SSADM - prototyp obrazovky - Špecifikácia dávkového vstupu/výstupu - štruktúra V/V z metódy SSADM - Backus - Naurova forma. V rámci vytvárania modelu budúceho IS sa povinne využívajú nasledovné špecifikačné jazyky : Činnosť Vyjadrovací jazyk - funkčná špecifikácia IS diagram dátových tokov - dátová špecifikácia IS entitno-relačné diagramy V rámci vytvárania modelu budúceho IS sa nepovinne, teda podľa potreby využívajú : diagram života entity, stavový diagram. 106

107 6.2.6 Vypracovanie Plánu akceptačného testovania IS Vo fáze Analýza IS sa na strane dodávateľa taktiež špecifikuje správanie sa IS k používateľom a prevádzkovateľovi. Zo strany podniku, odberateľa IS potrebné určiť spôsoby overovania požadovaného správania sa IS, čo môže byť predmetom poslednej etapy v rámci fázy, v ktorej sa navrhuje Plán akceptačného testovania IS. Plán akceptačného testovania IS by mal definovať tak testovacie dáta, ako aj testovacie procedúry, ktoré budú použité pre akceptačné testovanie Validácia výsledkov analýzy IS Vo fáze analýzy IS vznikajú dokumenty a produkty, ktoré zásadným spôsobom ovplyvňujú celý pripravovaný systém, ako aj budúce efekty z jeho prevádzkovania a používania. Kontrola, hodnotenie kvality, overenie a následné akceptovanie dokumentov vyplývajúcich z analýzy IS zabezpečuje základné predpoklady úspešného pokračovania procesu budovania IS v ďalších fázach jeho životného cyklu Komplex činností súvisiacich s hodnotením, overením, schválením a akceptovaním výsledkov analýzy IS nazývaný validácia Analytický projekt IS Analytický projekt IS vzniká sústredením získaných poznatkov do dokumentu, ktorý sa vypracováva s obsahom podľa internej normy riadenia spoločnosti dodávateľa IS. V kontexte 4. kapitoly týchto skrípt, ktorá opisuje najmä postup budovania IS pri uplatnení typového riešenia poznamenávame, že Analytický projekt nahrádza Rozdielovú štúdiu v rámci Realizačného projektu IS Plán akceptačných testov Plán akceptačných testov obsahuje detailný opis realizácie jednotlivých testov a kritériá, kedy je IS pre zadávateľa IS akceptovateľný. Z toho vyplýva, že testovací tím pre akceptačné testy by mal byť založený skôr, ako sa projekt dostal do fázy akceptačných testov. Testovací tím by mal spolupracovať s testovacími tímami, ktoré vykonávali testovanie vo fáze integrácie IS Štruktúra plánu akceptačných testov Definovanie plánov akceptačných testov je založené na štruktúrovanom návrhu. Štruktúra pozostáva z nasledovných komponentov: 107

108 skupiny scenárov, scenárov, série testov, testovacích prípadov (testovacích procedúr). Plán akceptačných testov potom pozostáva z niekoľkých skupín scenárov. Skupina scenárov je identifikovaná skupinou funkcií budovaného IS. Scenáre delia skupinu scenárov na nezávislé časti. Každý scenár ďalej obsahuje niekoľko sérií testov. Podobne sa série testov skladajú z jednotlivých testovaných prípadov. Testovacie prípady sa navrhujú s dvoma cieľmi. Prvý je pozitívny, kde je snaha potvrdiť správnu funkčnosť, druhý je negatívny, kde musí systém správne zareagovať na vstup, ktorý nie je správny a pod. Každý testovací prípad musí podrobne definovať čo sa bude testovať, aké testovacie dáta sa použijú a ako sa bude pri testovaní postupovať. Testovací prípad definuje očakávané výstupy, ktoré umožňujú jednoduchú kontrolu, či testovaný testovací prípad prebehol úspešne alebo neúspešne. Testovacie prípady sú niekedy označované ako testovacie procedúry. Do testovacích scenárov akceptačných testov je nevyhnutné zahrnúť nasledovné požiadavky : Požiadavky na dáta zber dát, archivácia dát, distribúcia dát, bezpečnosť dát, kapacita dát; Funkčné požiadavky pre potvrdenie požadovanej funkčnosti a cieľov zadávateľa; Výkonnostné požiadavky pre overenie výkonu, overenie oneskorenia pri reálnom zaťažení viacnásobných simultánnych transakcií, overenie zaťaženia centrálneho systému; Požiadavky rozhrania overenie, že externé a interné systémy prenášajú dáta správne a sú riadené v súlade zo špecifikáciou. Množstvo definovaných testov závisí od funkčnosti, rozsiahlosti systému a od množstva dát použitých pri testovaní Druhy akceptačných testov Existujú tri základné druhy akceptačných testov, ktorými sa ohodnocuje systém: Benchmarkový test, Pilotný test, Paralelné testovanie. 108

109 Pri benchmarkovom teste sa realizuje testovanie množiny testovacích prípadov, ktoré reprezentujú typické podmienky, za ktorých bude systém reálne prevádzkovaný. Pre každý testovaný prípad sa vyhodnotí funkčnosť a výkonnosť systému. Výhodou benchmarkového testovania je, že testovací tím je schopný overiť výkonnosť systému a porovnať ho s existujúcimi konkurenčnými systémami. Benchmarkové testy sa všeobecne používajú vtedy, ak má zadávateľ špeciálne požiadavky na výkonnosť systému. Pilotný test pracuje s experimentálnou fiktívnou bázou. Prevádzkovateľ preveruje funkčnosť systému, ako keby bol nasadený v reálnej prevádzke. Preverujú sa všetky funkcie systému, s ktorými príde používateľ denne do styku. Prevádzkovateľ zvyčajne pripraví zoznam úkonov, ktoré sa realizujú pri bežnej prevádzke. Realizácia takýchto testov je menej formálna než benchmarkový test. Ak sa testuje systém, ktorý sa bude používať pre širšiu vrstvu používateľov, vykonávajú sa dva druhy testov a to alfa a beta. Alfa test, ktorý sa vykonáva pred vlastným dodaním IS prevádzkovateľovi a Beta test, ktorý sa realizuje v prostredí prevádzkovateľa IS. Reprezentačná skupina prevádzkovateľov pre beta testy musí byť vybraná tak, aby pokryla rôznorodé potreby používateľov. Paralelné testovanie sa uplatňuje vtedy, ak je nový systém v prevádzke súčasne so starým systémom. Používatelia sa zoznamujú s novým systémom a posudzujú výkonnosť a funkčnosť nového systému v porovnaní so starým systémom. Paralelné testovanie je vlastne testovanie funkčnosti a kompatibility systémov v réžii prevádzkovateľa. Výsledok akceptačných testov by nám mal odpovedať na otázku, či bol vytvorený dobrý IS a či úplne (resp. v akom rozsahu ) spĺňa požiadavky podniku, odberateľa IS Riešenie bezpečnosti IS Z hľadiska zaistenia bezpečnosti IS v tejto fáze životného cyklu by mali prebiehať nasledovné procesy: a) Analýza a manažment rizík IS, b) Analýza stavu implementácie bezpečnostných opatrení v praxi Analýza a manažment rizík IS Bezpečnostný manažér IS zabezpečí realizáciu analýzy rizík a návrh bezpečnostného skeletu IS pre schválený variant budovania nového IS alebo schválený variant rozvoja už prevádzkovaného IS. Výsledkom analýzy a manažmentu rizík IS, okrem iného, bude aj nasledovná bezpečnostná dokumentácia IS: Manažérska správa o výsledkoch identifikácie a ohodnotenia aktív IS, Manažérska správa o výsledkoch identifikácie a ohodnotenia hrozieb a zraniteľnosti, ako aj zistených rizikách IS, Manažérska správa o navrhovanom bezpečnostnom skelete IS. 109

110 V rámci návrhu bezpečnostného skeletu IS je potrebné doriešiť aj možnosti uspokojenia bezpečnostných požiadaviek na IS špecifikované v štúdii IS, týkajúce sa schváleného variantu IS Analýza stavu implementácie bezpečnostných opatrení v praxi V prípade, keď ide o ďalší rozvoj už existujúceho IS, je potrebné analyzovať stav implementácie bezpečnostných opatrení daného IS v praxi. Sleduje sa tým cieľ zabrániť opakovanému riešeniu bezpečnostných problémov IS, ktoré už boli v minulosti nejako vyriešené. Samozrejme, už realizované bezpečnostné opatrenia je potrebné preveriť z hľadiska ich dostatočnosti za zmenených podmienok prevádzkovania IS a v odôvodnených prípadoch ich nahradiť inými vhodnejšími opatreniami. Výsledkom oboch opisovaných činností, okrem skôr spomínanej bezpečnostnej dokumentácie, súvisiacich s riešením bezpečnosti IS v tejto fáze životného cyklu IS bude vlastne: a) Bezpečnostný skelet nového IS alebo b) Program zvýšenia bezpečnosti inovovaného IS, ktorý bude sadou bezpečnostných opatrení, ktoré sa majú doimplementovať pre daný IS v rámci zaistenia jeho bezpečnosti v zmenených podmienkach Bezpečnostné testy zahrnuté do akceptačného testovania IS V súvislosti s plánovaním akceptačného testovania IS platí, že bezpečnostný manažér IS musí navrhnúť bezpečnostné testy, ktoré budú realizované ako súčasť akceptačného testovania. Dokumentácia bezpečnostných testov sa vypracováva s využitím toho istého inštrumentária ako ostatné testy, najmä funkčné a spoľahlivostné testy. Z predchádzajúceho textu vyplýva, že bezpečnostný projektant a/alebo bezpečnostný manažér IS v rámci fázy Analýza IS nevstupuje do Analytického projektu IS, ale vytvára vlastnú bezpečnostnú dokumentáciu Možné prístupy k realizácii fázy Pri zabezpečovaní tejto fázy životného cyklu IS je možné uplatniť niekoľko postupov: vykonanie analýzy IS a vytvorenie špecifikácie IS zadávateľom (najčastejšie útvar IT podniku), v spolupráci s používateľmi IS; 110

111 vytvorenie špecifikácie IS špecializovanou firmou, pričom vytvorená špecifikácia IS bude slúžiť ako súčasť zadania odovzdávaného riešiteľovi; vykonanie celej fázy a vytvorenie špecifikácie IS v rámci dodávky IS na kľúč, vybraným systémovým integrátorom. Aj v prípade, že fáza analýzy IS sa uskutoční dodávateľským spôsobom, je nutné zabezpečiť účasť zadávateľa a používateľov IS v procese vytvárania špecifikácie IS. Opísaný priebeh fázy - Analýza IS je možné znázorniť diagramom postupu prác, ktorý predstavuje obrázok č

112 Obrázok č Priebeh činností v rámci fázy - Analýza IS K Systém riadenia Plán budovania IS Štúdia IS Analýza a schválenie požiadaviek na IS Model požadovaného IS nie schválený? Špecifikácia IS Model budúceho IS nie schválená? Technická špecifikácia IS Technická špecifikácia IS nie schválená? Plán verifikácie Vypracovanie: Plánu verifikácie Plánu akceptaèného testovania Plánu kvality IS Plán akceptačného testovania IS Schválenie dokumentácie Plán kvality IS Stanoviská a protokoly nie Plány sú schválené? 1 112

113 Obrázok č Pokračovanie 113

114 6.3 Dokumenty vznikajúce v rámci fázy V rámci fázy Analýza IS životného cyklu IS budú vznikať nasledovné dokumenty : Analytický projekt IS, Stanoviská s posúdenia projektu, Protokol zo schvaľovania projektu, Plán akceptačného testovania IS, Stanoviská z posudzovania plánu, Protokol zo schvaľovania plánu Plán verifikácie Stanoviská z posudzovania plánu, Protokol zo schvaľovania plánu Plán kvality IS Stanoviská z posudzovania plánu, Protokol zo schvaľovania plánu Manažérska správa o výsledkoch identifikácie a ohodnotenia aktív IS, Manažérska správa o výsledkoch identifikácie a ohodnotenia hrozieb a zraniteľnosti, ako aj zistených rizikách IS, Manažérska správa o navrhovanom bezpečnostnom skelete IS Bezpečnostný skelet nového IS alebo Program zvýšenia bezpečnosti inovovaného IS Stanoviská k bezpečnostnej dokumentácií Protokoly zo schválenia bezpečnostnej dokumentácie. 6.4 Podmienky začatia a ukončenia fázy Fáza Analýza IS je začína schválením štúdie budovania IS. Fáza Analýza IS je ukončená schválením Analytického projektu IS, Plánu akceptačného testovania IS, Plánu kvality IS a Plánu validácie IS a bezpečnostnej dokumentácie IS vytvorenej v tejto fáze. 6.5 Zodpovednosť za realizáciu fázy Fázu Analýza IS zabezpečuje útvar podniku/spoločnosti zodpovedný za projektovanie IS. V praxi môže nastať odklon v zabezpečovaní tejto fázy životného cyklu IS, pretože dôjde k rozhodnutiu o uplatnení externých riešiteľských kapacít. Za takejto situácie útvar spoločnosti zodpovedá za celkovú koordináciu priebehu fázy, schvaľovanie výstupov a za jej uskutočnenie pri dodržaní platnej internej smernice. 114

115 7 Projektovanie IS 7.1 Rámcový opis fázy Podobne ako v prípade kapitoly 6 aj táto kapitola je napísaná s cieľom vysvetliť postup za situácie keď sa nevyužíva typové riešenie prispôsobované pre potreby podniku. Text teda opisuje situáciu keď sa bude vyvíjať nové riešenie. Cieľom fázy je navrhnúť celkovú softvérovú architektúru vyvíjaného IS a opísať logiku jednotlivých programových modulov (komponentov) IS. 7.2 Detailný opis fázy Fázu projektovania a návrhu je možné rozdeliť do dvoch základných krokov: návrh architektúry systému, návrh logiky modulov Návrh architektúry V rámci návrhu architektúry IS sa identifikujú základné subsystémy a ich vzťahy (vzájomné informačné a riadiace prepojenia), návrh používateľských rozhraní a spôsob komunikácie. Súčasťou návrhu architektúry je dekompozícia špecifikácie navrhovaného systému na špecifikácie modulov - samostatne realizovateľných komponentov IS, s presne vymedzenými funkciami, tokmi dát a riadením. Pri dekompozícii treba zohľadniť popri funkčných požiadavkách aj kvalitatívne požiadavky a bezpečnostné požiadavky (napr. kritické atribúty, požiadavky na ochranu a bezpečnosť, atď.). Finálny návrh architektúry systému môže vychádzať z posúdenia viacerých alternatív riešenia architektúry IS (s požadovanou funkčnosťou) a výberu najvhodnejšej z nich. Popri návrhu softvérovej architektúry IS je potrebné určiť spôsob integrácie jednotlivých komponentov (modulov) systému a spôsob overenia funkčnosti integrovaného systému. Preto sa vo fáze návrhu architektúry vytvára aj plán integračného testovanie, ktorý stanovuje spôsob zoskupovania navrhovaných komponentov systému do vyšších funkčných celkov, a definujú sa testovacie procedúry a dáta. V rámci návrhu architektúry je možné stanoviť aj postup nasadzovania komponentov vytváraného systému do prevádzky (stavebnicový prístup k vývoju IS). Priority pre vývoj a nasadzovanie jednotlivých komponentov IS určuje zadávateľ projektu IS. 115

116 7.2.2 Návrh logiky modulov Pri návrhu modulov sa transformuje špecifikácia každého modulu do detailnej špecifikácie programov, realizujúcich funkčné a kvalitatívne požiadavky na daný modul. Programová špecifikácia modulu pozostáva z: podrobného návrhu používateľských rozhraní (vstupov a výstupov) modulu, návrhu logickej a fyzickej štruktúry dát, a návrhu (logiky) algoritmov, realizujúcich požadované funkcie modulu. Programová špecifikácia je podkladom pre programátorov v etape kódovania (implementácie) modulov. Podobne ako pri návrhu architektúry IS, súčasťou návrhu modulov je aj určenie spôsobu overenia funkčnosti a spoľahlivosti jednotlivých modulov. Z tohto dôvodu sa pre každý špecifikovaný modul vytvára samostatný plán testovania modulu, ktorý obsahuje špecifikáciu testovacích procedúr a testovacích dát, spôsob overovania kritických atribútov, atď Riešenie bezpečnosti IS Z hľadiska zaistenia bezpečnosti IS nasledovné procesy: v tejto fáze životného cyklu, by mali prebiehať a) Vypracovanie bezpečnostnej dokumentácie IS, b) Vypracovanie plánu bezpečnostných testov realizovaných v rámci integračného testovania. Z uvedeného súčasne vyplýva, že bezpečnostný manažér IS nevstupuje do dokumentácie vypracovávanej inými špecialistami, ale vypracováva vlastnú bezpečnostnú dokumentáciu Vypracovanie bezpečnostnej dokumentácie IS V závislosti od druhu IS, ktorý je projektovaný, bezpečnostný manažér IS zaistí vypracovanie najmä tejto bezpečnostnej dokumentácie: Bezpečnostná politika IS, Bezpečnostný zámer IS, Bezpečnostný projekt IS, Bezpečnostné smernice IS, Havarijný plán a plán obnovy činnosti IS. 116

117 Odporúčaný obsah jednotlivých druhov bezpečnostnej dokumentácie IS je špecifikovaný v kapitole 16. Je veľmi pravdepodobné, že prvé verzie dokumentov, najmä bezpečnostných smerníc a havarijného plánu, ako aj plánu obnovy činnosti IS budú spresňované tesne pred začatím rutinnej prevádzky IS Vypracovanie plánu bezpečnostných testov realizovaných v rámci integračného testovania Integrácia modulov IS zaisťuje nielen funkčnosť IS ako celku, ale aj prepojenie častí IS, vrátane s tým súvisiacich bezpečnostných procesov. Či už ide o ochranu odovzdávaných dát, zabezpečenie ich integrity a dôvernosti alebo vykonávanie nejakých procedúr zo strany používateľov IS, všetko je potrebné náležite otestovať. V súvislosti s plánovaním integračného testovania IS platí, že bezpečnostný manažér IS musí navrhnúť bezpečnostné testy, ktoré budú realizované ako súčasť integračného testovania. Dokumentácia bezpečnostných testov sa vypracováva s využitím toho istého inštrumentária ako ostatné testy, najmä funkčné a spoľahlivostné testy. Postupnosť činností v rámci fázy projektovania IS možno zjednodušenie vyjadriť diagramom postupu prác, ktorý je znázornený obrázkom č

118 Obrázok č Priebeh činností v rámci Projektovania IS Z Špecifikácia IS Návrh archtektúry IS Architektúra IS nie schválená? Vytvorenie plánu testovania modulov Plán testovania modulov nie schválený? Vytvorenie Plánu integrácie a testovania IS Plán integrácie a testovania nie schválený? Plán vývoja SW Plán vývoja SW nie schválený? nie Zmeny? 1 118

119 Obrázok č Pokračovanie 119

120 7.3 Dokumenty vznikajúce v rámci fázy V rámci fázy vznikajú nasledovné hlavné a ostatné dokumenty : Návrh architektúry systému, vrátane logiky modulov, Stanoviská k architektúre, Protokol o schválení architektúry, Plán integrácie a testovania IS, Stanoviská k plánu, Protokol o schválení plánu, Plán testovania modulov, Stanoviská k plánu, Protokol o schválení plánu, Plán vývoja SW, Stanoviská k plánu, Protokol o schválení plánu Bezpečnostná dokumentácia IS o Bezpečnostná politika IS, o Bezpečnostný zámer IS, o Bezpečnostný projekt IS, o Bezpečnostné smernice IS, o Havarijný plán a plán obnovy činnosti IS o Stanoviská k bezpečnostnej dokumentácii o Protokoly zo schválenia bezpečnostnej dokumentácie. 7.4 Podmienky začatia a ukončenia fázy Podmienky začatia fázy sú nasledovné: odsúhlasená Špecifikácia IS, v prípade externého riešiteľa uzavretá zmluva o dielo s dodávateľom na vytvorenie IS na základe dodanej špecifikácie. Podmienky ukončenia fázy sú nasledovné: prebratie dokumentácie k fáze; zadávateľ môže pre formálne ukončenie fázy projektovania a návrhu IS vyžadovať odsúhlasenie vybraných dokumentov. 7.5 Zodpovednosť za realizáciu fázy Zodpovednosť za realizáciu fázy má riešiteľ projektu, teda dodávateľ IS. 120

121 8 Vývoj SW 8.1 Rámcový opis fázy Fáza vývoja spočíva v kódovaní (programovaní) jednotlivých modulov vytváraného IS v dohodnutom implementačnom prostredí (programovacom jazyku). Cieľom tejto fázy je: programovo realizovať programové špecifikácie všetkých modulov, definovaných v architektúre IS; vypracovať podrobnú programovú dokumentáciu k jednotlivým vytvoreným programovým modulom, resp. systémovú dokumentáciu. 8.2 Detailný opis fázy Fáza - Vývoj SW sa člení na nasledovné etapy : kódovanie / programovanie, testovanie programov, vytvorenie dokumentácie k programom, vytvorenie produkčnej verzie modulov, vytvorenie používateľskej príručky špecifikácia testovania modulov špecifikácia integračného testovania IS riešenie bezpečnosti IS Kódovanie - programovanie Členovia vývojových tímov programujú jednotlivé moduly IS tak, aby vytvorené programové vybavenie plne pokrylo požadované funkcie modulov IS. Využívajú pritom normy platné pre programovanie. V kontexte 4. kapitoly dodávame, že časť realizačných tímov sa v prípade vývoja nového OS nahrádza vývojovými tímami Testovanie programov Počas vývoja jednotlivých modulov systému sa vykonáva i prvá fáza testovania. V tejto etape slúži k internému overeniu funkčnosti vytváraného modulu a vykonáva ho tvorca zdrojových programov. Z tohto dôvodu nie je potrebné vytvoriť protokol z testovania. 121

122 8.2.3 Vytvorenie dokumentácie k programom Zdrojové texty programov sú opísané v dokumentácii s názvom Programová a systémová dokumentácia, ktorá taktiež opisuje podmienky inštalácie SW a jeho prevádzky Vytvorenie používateľskej dokumentácie Vytváraná používateľská dokumentácia zvyčajne pozostáva z inštalačnej, referenčnej a používateľskej príručky. Na dopracovanie používateľskej dokumentácie nadväzuje začiatok školenia budúcich používateľov systému Špecifikácia testovania modulov Moduly sa skladajú z rôzneho množstva samostatných programov, ktoré pri prevádzke IS vzájomne spolupracujú. Súčasťou budovania nového IS potom je aj overenie funkčnosti celého modulu. S tým súvisí príprava plánov pre testovanie modulov IS. Ich príprava prebieha na strane dodávateľa IS v tejto fáze Špecifikácia integračného testovania IS IS sa skladá z jednotlivých podsystémov, ktoré sa skladajú z jednotlivých modulov. jednotlivé moduly a podsystému vzájomne spolupracujú pri prevádzke IS. Súčasťou budovania nového IS potom je aj overenie funkčnosti celého IS. S tým súvisí príprava plánov pre integračné testovanie IS. Ich príprava prebieha na strane dodávateľa IS v tejto fáze Riešenie bezpečnosti IS Z hľadiska zaistenia bezpečnosti IS nasledovné procesy: v tejto fáze životného cyklu, by mali prebiehať a) Dohľad nad implementáciou bezpečnostných opatrení v aplikačnom softvéri, b) Vypracovanie bezpečnostných príručiek Dohľad nad implementáciou bezpečnostných opatrení v aplikačnom softvéri Súčasťou bezpečnostného skeletu IS sú aj bezpečnostné opatrenia, ktoré musia byť zabudované do samotnej aplikačnej časti IS, teda do softvéru. 122

123 Ide najmä o opatrenia týkajúce sa: validácie vstupných dát, riadenia interného spracovania, autentizácie výstupných správ, validácie výstupných dát, uplatnenia kryptografických opatrení. Bezpečnostný manažér IS vykonáva dohľad nad implementovaním týchto opatrení do vytváraných softvérových modulov Vypracovanie bezpečnostných príručiek V závislosti od povahy IS a dát, ktoré budú IS spracúvané môže vzniknúť potreba vypracovať bezpečnostných príručiek pre niektoré skupiny používateľov a/alebo administrátorov či správcov. Ich vypracovanie zvyčajne zabezpečuje bezpečnostný manažér IS. Postupnosť činností v rámci fázy vývoja SW IS možno zjednodušenie vyjadriť diagramom postupu prác, ktorý je znázornený obrázkom č

124 Obrázok č Priebeh činností v rámci fázy Vývoj SW Z Plán vývoja SW Špecifikácia IS Architektúra IS Programovanie Zdrojové programy modulov nie schválené? Vytvorenie programovej a systémovej dokumentácie Programová a systémová dokumentácia Vytvorenie používateľskej dokumentácie Používateľská dokumentácia IS nie schválená? Špecifikácia procedúr a dát pre testvanie modulov Špecifikácia testov Špecifikácia procedúr a dát integračného tes tovania IS Špecifikácia testov áno Schválená? 1 124

125 Obrázok č Pokračovanie 125

126 8.3 Dokumenty vznikajúce v rámci fázy V rámci fázy Vývoj SW vznikajú nasledovné dokumenty: zdrojové programy modulov, programová a systémová dokumentácia, používateľská dokumentácia špecifikácia testovanie modulov špecifikácia integračného testovania IS bezpečnostné príručky stanoviská protokoly zo schválenia dokumentov. 8.4 Podmienky začatia a ukončenia fázy Podmienky začatia fázy sú nasledovné: ukončený návrh architektúry systému a návrh logiky modulov. Podmienky ukončenia fázy sú nasledovné: prebratie dokumentácie vytvorenej v rámci fázy. Zadávateľ môže pre formálne ukončenie fázy vývoja SW vyžadovať odsúhlasenie vybraných dokumentov. 8.5 Zodpovednosť za realizáciu fázy Zodpovednosť za realizáciu fázy má riešiteľ projektu, teda dodávateľ nového IS. 126

127 9 Budovanie HW a SW platformy IS 9.1 Rámcový opis fázy Cieľom tejto fázy je navrhnúť, špecifikovať, naplánovať a vybudovať HW platformu budovaného IS, osadiť HW základným softvérom, vrátane testovania dodanej techniky a základného SW. Súčasťou je aj riešenie bezpečnosti IS. 9.2 Detailný opis fázy Rozpracovanie architektúry a topológie IS V tejto fáze dodávateľ IS detailne rozpracúva rámcovú architektúru a topológiu nového IS vytvorenú zadávateľom ako súčasť zadania pre vydudovanie nového IS, pozri kapitolu Vecnou postatou riešenie hardvérovej platformy IS je detailný návrh technického riešenia IS, vrátane dodávateľov, určenie počtu a parametrov jednotlivých druhov komponentov (technických zariadení), jeho priestorové rozmiestnenie v objektoch spoločnosti, ako aj určenie rozhraní voči okolitému prostrediu. V tejto fáze je potrebné potvrdiť alebo spresniť základné SW riešenia IS, predovšetkým vybrať vhodné operačné systémy, DB prostredia, používané jazyky, generátory, komerčné aplikačné systémy a pod. Technické prostriedky budovaného IS (bez ohľadu na architektúru) možno rozdeliť na 6 oblastí: centrálne servery,vrátane založných, servery organizačných jednotiek, používateľské PC, prídavné zariadenia, sieťová infraštruktúra o kabeláž o aktívne prvky ochranné a bezpečnostné prvky. Pri návrhu jednotlivých komponentov musí byť braná do úvahy potrebná kvalita, funkčnosť a spoľahlivosť, bezpečnosť, ale aj univerzalita a perspektívna 127

128 obnoviteľnosť. Dôležité je zohľadniť prípadné požiadavky, ktoré vznikli počas vývoja IS, teda nemohli byť poznané predtým. Dôležitý krok predstavuje priestorové rozmiestnenie navrhnutých technických zariadení v objektoch podniku a ich osadenie základným SW, pozri kapitolu Po uzatvorení dekompozácie SW na moduly je potrebné vykonať aj priradenie aplikačných modulov rozmiestneným technickým zariadeniam, čím sa určí rozloženie spracovacích procesov IS v objektoch spoločnosti. Netreba zabúdať na osvedčené dvojstupňové budovanie HW a SW platformy IS, ktoré súvisí s vytvorením prostredia pre skúšanie IS a následne plnú prevádzku IS v celom podniku Vytvorenie plánu dodávok a rozmiestnenia HW Nový IS môže vyžadovať nákup rôznej techniky od serverov cez pracovné stanice, tlačiarne až po rôzne komponenty sieťovej infraštruktúry. Dobrou zásadou je naplánovať a zabezpečiť potrebnú techniku najskôr pre skúšobnú prevádzku nového IS, následne pre ostatné pracoviská. Plán dodávok techniky a zariadení v rátane softvéru môže zabezpečovať tak podnik, ako aj dodávateľ IS. Závisí od konkrétnych zmluvných podmienok kto túto činnosť reálne vykoná Rozmiestnenie HW Podobne ako v prípade vytvárania plánu dodávok a j v tomto prípade platí, že závisí od konkrétnych zmluvných podmienok kto túto činnosť reálne vykoná, pretože to môže vykonať tak podnik, ako aj dodávateľ IS, prípadne v nejakom režime spoluúčasti. Účasť podniku je nutná aj vtedy, ak rozmiestnenie, oživenie a osadenie HW základným softvérom zabezpečuje dodávateľ, pretože vstupovať na pracoviská podniku s cieľom rozmiestniť techniky a vykonať ďalšie práce by bolo v rozpore s dobrými bezpečnostnými zásadami Riešenie bezpečnosti IS Z hľadiska zaistenia bezpečnosti IS nasledovné procesy: v tejto fáze životného cyklu by mali prebiehať a) Dohľad nad dodávkou HW a SW; b) Dohľad nad inštalovaním HW a SW; c) Dohľad nad nastavovaním bezpečnostných parametrov OS, DB, aplikácií, sieťového prostredia; d) Dohľad nad vytváraním prvotných používateľov a ich prístupových práv; e) Dohľad nad fyzickou a objektovou bezpečnosťou. 128

129 Dohľad nad dodávkou HW a SW Vecnou podstatou dohľadu nad dodávkou HW a základného SW je zaistenie toho, aby nakupovaný HW a SW: mal požadované bezpečnostné vlastnosti, bol kompatibilný s už existujúcou platformou IS a nemal negatívny vplyv na existujúcu bezpečnosť IS Dohľad nad inštalovaním HW a SW Vecnou podstatou dohľadu nad inštalovaním HW a SW je zaistiť, aby bol inštalovaný HW a SW s dohodnutou konfiguráciou, resp. aby vytváraná alebo dobudovávaná platforma IS mala predpísanú konfiguráciu Dohľad nad nastavovaním bezpečnostných parametrov OS, DB, aplikácií, sieťového prostredia Dohľad nad nastavovaním bezpečnostných parametrov OS, DB, aplikácií, sieťového prostredia je jedným z kľúčových procesov, ktoré môžu mať priamy dopad na budúcu prevádzkovú bezpečnosť IS. BMIS by mal byť prítomný pri nastavovaní bezpečnostných parametrov kľúčových komponentov IS Dohľad nad vytváraním používateľov a ich prístupových práv Dohľad nad vytváraním používateľov a ich prístupových práv je ďalším z kľúčových procesov, ktoré môžu mať priamy dopad na budúcu prevádzkovú bezpečnosť IS. BMIS by mal byť prítomný pri vytváraní kľúčových rolí existujúcich v tíme prevádzkujúcom IS a nastavovaní ich oprávnení, ako aj pri vytváraní vybraných používateľov Dohľad nad fyzickou a objektovou bezpečnosťou Opatrenia pre fyzickú a objektovú bezpečnosť a chránia IS pred viacerými vážnymi hrozbami. sú súčasťou bezpečnostného skeletu IS Preto zaistenie toho, že plánované bezpečnostné opatrenia boli realizované a fungujú správne, je vážnou povinnosťou bezpečnostného manažéra IS. Na druhej strane bezpečnostný manažér IS tieto opatrenia sám nerealizuje ale dohliada na ich realizáciu. Preto sa minimálne zúčastňuje procesu preberania už zrealizovaných bezpečnostných opatrení. 129

130 Postupnosť činností v rámci fázy Budovanie HW platformy IS možno zjednodušenie vyjadriť diagramom postupu prác, ktorý je znázornený obrázkom č

131 Obrázok č Priebeh činností vo fáze Budovanie HW a základného SW Z Architektúra IS Špecifikácia HW a základného SW Špecifikácia HW a SW nie schválená? Vytvorenie Plánu dodávok, nasadzovania a testovania HW a základného SW Plán nie schválené? Dodávka, nasadzovanie sa testovanie HW a zákldného SW Protokoly áno Reklamácie? áno Zmeny? 1 131

132 Obrázok č Pokračovanie 132

133 9.3 Dokumenty vznikajúce v rámci fázy V rámci fázy Budovanie HW platformy IS vznikajú nasledovné dokumenty : Návrh a špecifikácia HW komponentov; Plán dodávok, nasadzovania a testovania HW komponentov Protokoly o rozmiestnení HW a nainštalovaní základného SW. 9.4 Podmienky začatia a ukončenia fázy Podmienkou začatia fázy je odsúhlasenie Špecifikácia IS. Podmienky ukončenia fázy sú nasledovné: odsúhlasenie skladby HW platformy; schválenie Plán dodávky, nasadzovania a testovania HW komponentov IS ukončenie procesu rozmiestňovania nakúpeného HW a inštalovania základného softvéru, oživenie serverov, PC a komunikačnej infraštruktúry. 9.5 Zodpovednosť za realizáciu fázy Zodpovednosť za realizáciu fázy má dodávateľ IS v spolupráci so zadávateľom. 133

134 10 Integrácia a testovanie IS 10.1 Rámcový opis fázy V tejto fáze životného cyklu IS ide jednak o dôkladné otestovanie funkčnosti, účinnosti a ďalších dôležitých vlastností jednotlivých modulov budúceho integrovaného celku, ako aj o samotnú integráciu modulov do funkčných subsystémov a testovanie ich funkčnosti v rámci fungovania celého IS. Súčasťou je aj riešenie bezpečnosti IS Detailný opis fázy Keďže tejto etape životného cyklu IS predchádza ukončená etapa implementácie, sú už k dispozícii programové kódy jednotlivých modulov IS. Je potrebné posúdiť funkčnosť modulov (či je v zhode s požiadavkami zadávateľa) a ich integrovateľnosť do funkčných celkov v rámci IS. Na to je potrebné vykonať testy. Oporným bodom pri tejto činnosti by mal byť predovšetkým dokument vytvorený v predošlých fázach životného cyklu IS - Plán testovania modulov a integrácie systému. Časovo sa vytvorenie takéhoto dokumentu bude viazať pravdepodobne na fázu návrhu komponentu IS Integrácia a testovanie modulov Pri testovaní modulov sa testuje každý samostatný softvérový modul podľa plánu testovania modulu. Výsledky testovania je potrebné zachytiť v protokole o testovaní. V prípade, že boli vopred špecifikované určité kritické vlastnosti (dôležité atribúty) a stanovené určité intervaly povolených hodnôt, je pri testovaní dôležité klásť dôraz na ich spĺňanie. Ak testovaný modul nevyhovuje stanoveným kritériám, či už z hľadiska testovania alebo z hľadiska merania kritických vlastností, je potrebné túto skutočnosť oznámiť vedeniu projektu a zvážiť možné kroky, ktoré by viedli k odstráneniu nevyhovujúceho stavu. V zásade možno nevyhovujúce výsledky odstrániť: buď len opravami implementácie modulu (zásahmi do zdrojového kódu) alebo (ak nevyhovujúci stav nemožno riešiť predošlým spôsobom), prepracovaním logiky modulu, teda zmenou spôsobu dosahovania požadovanej funkčnosti. Pochopiteľne, ani v tomto prípade pravdepodobne nebude možné vyhnúť sa zásahom do kódu modulu. Následne, po takomto zákroku, je potrebné opäť aplikovať na opravený modul procedúru testovania a všetky uvedené kroky opakovať až do dosiahnutia uspokojivých výsledkov. 134

135 Integrácia a testovanie IS Po úspešnom otestovaní softvérových modulov možno plynulo prejsť k samotnej integrácii a testovaniu celého informačného systému. Pri spájaní modulov do vyšších funkčných celkov je opäť potrebné sledovať a testovať ich funkčnosť. Podobne ako pri testovaní modulov, aj tu je predpokladom vopred špecifikovaná funkčnosť a kritické vlastnosti, presne definované v pláne integrácie a testovania. V prípade, že integrované subsystémy nevyhovujú požadovaným kritériám, je opäť potrebné po konzultácii s vedením projektu zvážiť zmeny v logike a architektúre systému. Výsledky a priebeh integrácie a testovania je potrebné zachytiť v protokole o integrácii a testovaní IS. Je výhodné, aj sa testovania vykonávaného dodávateľom zúčastňujú aj vybraní pracovníci podniku, budúceho prevádzkovateľa IS. Získajú tým poznatky pre následné podnikom zabezpečované akceptačné testovanie ako aj rutinné využívanie IS Špecifikácia konfigurácie systému Po ukončení integračného testovania IS je možné zo strany dodávateľa IS uzatvoriť konfiguráciu systému, ktorá bude odovzdaný odberateľovi, teda podniku budujúcemu IS, na akceptovanie a následne na prevzatie do rutinnej prevádzky Riešenie bezpečnosti IS Z hľadiska zaistenia bezpečnosti IS nasledovné procesy: v tejto fáze životného cyklu by mali prebiehať a) Realizácia bezpečnostných testov zahrnutých do integračného testovania, b) Dohľad nad konfiguráciou systému Realizácia bezpečnostných testov zahrnutých do integračného testovania V tejto fáze životného cyklu sa musia uskutočniť, vyhodnotiť a prípadne prijať korekčné opatrenia vyplývajúce z výsledkov bezpečnostných testov zahrnutých do integračného testovania Dohľad nad konfiguráciou systému Pod konfiguráciou systému sa rozumie zoznam a opis jednotlivých modulov a ich verzií, z ktorých sa skladá aktuálny IS. Ďalej sú tu opísané procedúry vykonané pre zostavenie aktuálnej konfigurácie systému a počiatoční používatelia s ich prístupovými právami. 135

136 Bezpečnostný manažér IS vykonáva dohľad nad spresnením konfigurácie systému na základe výsledkov integračného testovania a ich výsledkov. Konfigurácia systému uzatvorená po skončení integračných testov je tou, ktorá je zhotoviteľom IS určená pre budúcu rutinnú prevádzku IS. Postup činností v rámci fázy Integračné testovanie IS je možné znázorniť diagramom postupu prác, ktorý je prezentovaný obrázkom č

137 Obrázok č Priebeh činností v rámci fázy Integrácia a testovanie IS Z Procedúry a dáta Plán testovania modulov áno Integrácia a testovanie modulov Potreba úpravy implementácie modulu? Protokoly áno Potreba prepracovania logiky modulu? áno Ïalší modul? Vypracovanie správy o integrácii a testovaní modulov Správa Integrácia a testovanie IS Protokoly áno Potrebná oprava implementácie? áno Potreba prepracovania logiky IS? áno Ïalšie integraèné testy? Vypracovanie správy o integrácii a testovaní IS Správa 1 137

138 Obrázok č Pokračovanie 1 Plán a scenáre testovania Realizácia bezpečnostných testov zahrnutých do integračného testovania Protokoly nie Schválené Dohľad nad konfiguráciou systému Protokoly nie Schválené Koniec 138

139 10.3 Dokumenty vznikajúce v rámci fázy Vo fáze integrácie a testovania IS vznikajú nasledovné dokumenty: Protokoly o testovaní modulov, Protokol o integrácii a testovaní systému, Správa o výsledku integrácie systému Správa o výsledku integračného testovania celého IS Špecifikácia konfigurácie systému Protokol o testovaní modulov Dokument je vytváraný riešiteľom informačného systému. Využije sa najmä v nasledujúcej fáze životného cyklu IS - vo fáze preberania systému a akceptačného testovania. Protokol obsahuje nasledovné údaje pre každý modul: opis vykonaných testov daného modulu; výsledky testovania a ich zhodnotenie; informácie týkajúce sa merania kritických vlastností daného modulu; zoznam zistených problémov a potenciálnych slabín, vrátane možností ich eliminácie Protokol o integrácii a testovaní systému Tento dokument je vytváraný riešiteľom IS. Vytvára sa po ukončení integrácie systému, najneskôr po skúšobnej inštalácii systému u prevádzkovateľa. Hlavné využitie protokolu je vo fáze preberania systému prevádzkovateľom/zadávateľom. Priebeh a podmienky vypracovania a odovzdania Protokolu o integrácii a testovaní systému, rovnako ako Protokolu o testovaní modulov by mali byť zachytené v zmluve medzi zadávateľom projektu a riešiteľom. Vo všeobecnosti zadávateľ projektu prijíma ukončenie fázy budovania IS prebratím príslušných protokolov. Protokol o integrácii a testovaní systému by mal obsahovať všetky vykonané kroky integrácie. Základný opis každého kroku integrácie obsahuje zoznam integrovaných modulov a subsystémov. Je potrebné uviesť spôsob a účel príslušnej integrácie. Ďalšou dôležitou položkou sú všetky testy vykonané pre integrovaný celok a údaje o výsledku merania kritických vlastností subsystému. V závere musí protokol obsahovať zhodnotenie výsledkov testovania a súpis existujúcich a potenciálnych problémov, ktoré boli identifikované v priebehu fázy a možnosti ich riešenia. 139

140 Konfigurácia systému Z dlhodobého hľadiska ide azda o najdôležitejší dokument, ktorý vzniká v tejto fáze tvorby IS, nakoľko je okrem fázy preberania, nevyhnutný pre následnú údržbu IS. Ide o zoznam a popis jednotlivých modulov a ich verzií, z ktorých sa skladá aktuálny IS. Ďalej sú tu opísané procedúry vykonané pre zostavenie aktuálnej konfigurácie systému a počiatoční používatelia s ich prístupovými právami. Dokument vypracúva riešiteľ po integrácii a prípadnej skúšobnej inštalácii u prevádzkovateľa. Zadávateľ/prevádzkovateľ dokument preberie a súčasne preverí riešiteľom udávanú konfiguráciu inštalovaného systému Podmienky začatia a ukončenia fázy Fáza Integrácia a testovanie IS sa začína po ukončení fázy vývoja SW v dohodnutom termíne, ktorý vyplýva z platného Plánu budovania IS. Fáza Integrácia a testovanie IS končí protokolárnym prevzatím Konfigurácie IS Zadávateľom IS Zodpovednosť za realizáciu fázy Zodpovednosť za realizáciu fázy má riešiteľ IS, ktorý v primeranom rozsahu spolupracuje so zadávateľom IS. 140

141 11 Akceptačné testovanie IS 11.1 Rámcový opis fázy V tejto fáze životného cyklu IS je potrebné detailne otestovať funkčnosť celého IS z hľadiska požiadaviek zadávateľa, teda podniku budujúceho nový IS. Súčasťou tejto fázy je aj zaškoľovanie budúcich používateľov IS. Keďže ide o predposlednú fázu životného cyklu IS, je zavŕšená protokolárnym odovzdaním IS používateľovi, ktorý ho zaužívaným postupom uvádza do rutinnej prevádzky. Súčasťou je aj riešenie bezpečnosti IS Detailný opis fázy V predchádzajúcej fáze životného cyklu IS, vo fáze integračného testovania už boli vykonané systémové a integračné testy, ktoré vykonal riešiteľ IS vo vlastnej réžii. Fáza akceptačného testovania sa líši v tom, že testovanie prebieha v réžií zadávateľa IS a cieľom je overiť, či IS pracuje podľa jeho požiadaviek, ktoré boli formulované v zadaní pre vývoj IS a boli následne potvrdené alebo spresnené vo fáze analýzy IS. Výsledkom akceptačných testov má byť spokojnosť zadávateľa s preberaným IS. Vstupom pre akceptačné testovanie sú požiadavky zadávateľa a špecifikácie akceptačných testov, vytvorené vo fáze analýzy IS. Akceptačné testovanie sa realizuje v spolupráci zadávateľa (útvar IT podniku), budúceho prevádzkovateľa (útvar IT podniku), budúcich používateľov systému (zástupcovia rôznych útvarov centrály podniku a organizačných zložiek) a samozrejme tvorcu IS, najčastejšie systémového integrátora IS. Fáza Akceptačné testovanie pozostáva z troch etáp : vlastné akceptačné testovanie, zaškoľovanie používateľov, odovzdávanie IS zadávateľovi Vlastné akceptačné testovanie Pre začatie akceptačného testovania sú potrebné nižšie uvedené materiály a dáta: Špecifikácia akceptačných testov, Plán akceptačných testov, 141

142 Nainštalovaný integrovaný IS, Konfigurácia systému, Testovacie dáta a testovacie skripty Špecifikácia akceptačných testov Špecifikácia akceptačných testov vychádza z požiadaviek zadávateľa IS. Tie však vždy nepostihujú celkovú aktivitu používateľa, preto musí špecifikácia akceptačných testov vychádzať nielen z požiadaviek zadávateľa IS, ale aj z modelu aktivít používateľa a prevádzkovateľa IS. To znamená, že je potrebné identifikovať podstatné používateľské aktivity, ako aj aktivity prevádzkovateľa IS a k nim vytvoriť podrobné špecifikácie akceptačných testov spolu s definíciou kladného a záporného výsledku testu. Pri návrhu testov sa neuvažuje s vnútorným prepojením modulov, ale dôraz sa kladie len na opis systému a aktivity používateľa a prevádzkovateľa IS Nainštalovaný integrovaný IS Akceptačné testovanie sa vykonáva v prostredí, ktoré sa čo najviac podobá reálnej prevádzke. Výhodné je vykonávať testovanie v prostredí, kde bude IS reálne nasadený. Tým sa odhalia problémy pri inštalovaní a nasadzovaní systému do rutinnej prevádzky v rámci celého podniku Konfigurácia systému Dokument obsahujúci konfiguráciu systému je nevyhnutný pre akceptačné testovanie IS a následnú reálnu prevádzku. Mal by byť vypracovaný v predchádzajúcej fáze - fáze Integračného testovania IS. Dokument musí obsahovať opis, verzie a nastavenia jednotlivých modulov systému, podľa ktorých sa systém nakonfiguruje pred začatím akceptačného testovania Testovacie dáta a testovacie skripty Testovacie dáta sú nevyhnutné na správne overenie funkčnosti modulov systému. V prípade databázových systémov je potrebné vytvoriť testovaciu databázu čo najviac podobnú reálnej prevádzke. Testovacie dáta môžu byť fiktívne vytvorené alebo sú prebraté z existujúceho funkčného systému zadávateľa. Ak prechádza zadávateľ zo starého IS na nový, sú súčasťou dodávky IS musia byť aj nástroje na migráciu dát zo starého systému do nového systému. Testovacie skripty sú programy alebo dáta, ktoré umožňujú automatizovane testovať vybranú funkčnosť IS. 142

143 Testovací tím Predpokladom pre úspešné akceptačné testovanie je správny výber testovacieho tímu a dôkladne pripravený plán akceptačných testov. Príprava plánu akceptačných testov už v čase testovania je nevhodná, pretože v časovej tiesni sa nezachytia všetky potrebné aktivity, ktoré je potrebné otestovať. Testovací tím by mal pozostávať najmä z pracovníkov podniku, najmä zo všetkých účastníkov vývoja IS, zadávateľa, používateľov a prevádzkovateľa IS. V tíme by sa však mali nachádzať aj pracovníci podniku, ktorí sa nepodieľali priamo na vývoji. Nutnou súčasťou tímu sú aj vybraní pracovníci dodávateľa, aby pomohli pri riešení vyskytujúcich sa problémov.. Prvou úlohou testovacieho tímu je pripraviť Plán akceptačných testov IS, preto musí byť menovaný ešte na začiatku realizácie projektu budovania IS.. Najvýznamnejšia činnosť testovacieho tímu spočíva však v realizácii akceptačného testovania podľa platného plánu Plán akceptačných testov Plán akceptačných testov určuje, ktoré testy v rámci akceptačného testovania má vykonať testovací tím. Súčasne obsahuje špecifikáciu podmienok, za ktorých majú jednotlivé testy prebiehať Zaškoľovanie používateľov Je vhodné, aby akceptačné testovanie vykonával akceptačný tím spolu s budúcimi používateľmi IS. Týmto spôsobom sa budúci používatelia najrýchlejšie zoznámia s novým systémom a zároveň majú možnosť konzultovať niektoré kroky priamo s tvorcami systému, ktorí sa nachádzajú v testovacom tíme. Používatelia systému sa môžu školiť súčasne s vykonávaním akceptačných testov alebo po ich skončení. Účastníci školenia však musia byť evidovaní a musí byť vedená evidencia o obsahu školenia a účasti používateľov. Jednotlivé školenia musia byť dobré pripravené aby pracovníci podniku získali všetky potrebné informácie pre využívanie nového IS, pozri kapitolu č Odovzdávanie IS zadávateľovi Po vykonaní akceptačných testov podnik rozhodne, či nájdené chyby umožňujú formálne prebrať hotový IS. Ak je to možné, potom zo strany dodávateľa v dohodnutom termíne dôjde k protokolárnemu odovzdaniu nového IS a zo strany podniku k prevzatiu IS. 143

144 Každá z chýb musí mať stanovenú prioritu riešenia a náročnosť na jej odstránenie. Potom sa v odovzdávacom a preberacom protokole, prípadne v prílohe uvedú všetky nájdené chyby pri testovaní. Ak pri odovzdávaní IS zadávateľovi ešte existujú nejaké chyby, súčasťou preberacieho protokolu sú aj podmienky dohodnuté pre ich odstránenie Riešenie bezpečnosti IS Z hľadiska zaistenia bezpečnosti IS nasledovné procesy: by v tejto fáze životného cyklu mali prebiehať a) Realizácia bezpečnostných testov zahrnutých do akceptačného testovania, b) Dohľad nad zaškolením používateľov, c) Dohľad nad protokolárnym prevzatím IS do rutinnej prevádzky Realizácia bezpečnostných testov zahrnutých do akceptačného testovania V tejto fáze životného cyklu IS je potrebné realizovať a vyhodnotiť bezpečnostné testy pripravené pre akceptačné testovanie v predchádzajúcich fázach. Na základe výsledkov akceptačných testov je podľa potreby potrebné prijať korekčné opatrenia, ktoré zaistia odstránenie zistených nedostatkov. Realizáciu bezpečnostných testov, zahrnutých do akceptačného testovania zo strany budúceho prevádzkovateľa, zabezpečuje bezpečnostný manažér IS Dohľad nad zaškolením používateľov Predpokladom bezproblémového, ale aj bezpečného prevádzkovania IS je dobrá príprava budúcich používateľov na prácu so systémom. Súčasťou zaškolenia nie je len zvládnutie nových funkčností, ale aj nácvik bezpečnostných procedúr. Dohľad nad zaškoľovaním používateľov zo strany budúceho prevádzkovateľa zabezpečuje bezpečnostný manažér IS Dohľad nad protokolárnym prevzatím IS do rutinnej prevádzky Práve existujúca zostava IS preberaná do rutinnej prevádzky od zhotoviteľa je tým prvkom, ktorý určuje základ budúcej prevádzkovej bezpečnosti IS. 144

145 Dôkladné zdokumentovanie bezpečnostného manažmentu IS. preberaného IS je preto veľmi významným prvkom Protokol o preberaní IS by mal byť verným obrazom toho, čo sa od zhotoviteľa reálne preberá. Dohľad zo strany budúceho prevádzkovateľa zabezpečuje bezpečnostný manažér IS. Postup činností v rámci fázy Akceptačné testovanie je možné znázorniť diagramom postupu prác, ktorý prezentuje obrázok č

146 Obrázok č Priebeh činností v rámci fázy Akceptačné testovanie Z Procedúry a dáta Plán testovania modulov nie Akceptačné testovanie IS (Vrátane bezpečnostných testov) Vyhovuje kritériám? Protokoly áno Vypracovanie správy o akceptačnom testovaní IS Správa nie Schválené Zaškolenie používateľov a prevádzkovateľa IS (Vrátane bezpečnostných školení) Protokoly nie Schválené Odovzdanie a prevzatie IS Protokoly nie Schválené K 146

147 11.3 Dokumenty vznikajúce v rámci fázy Vo fáze akceptačného testovania IS vznikajú nasledovné dokumenty: Protokol o akceptačnom testovaní, Protokol o zaškolení používateľov systému, Odovzdávací a preberací protokol Protokol o akceptačnom testovaní Dokument je vytváraný prevádzkovateľom informačného systému v súlade s plánom akceptačného testovania. Vytvára sa po ukončení akceptačného testovania. Dokument musí obsahovať informácie o priebehu a výsledkoch akceptačného testovania. Dokument je schvaľovaný zadávateľom IS po overení používateľmi a prevádzkovateľom systému. Protokol je nevyhnutný pre formálne prevzatie systému, pretože až po jeho schválení, môže prevádzkovateľ uvažovať o skutočnom prevzatí systému. Protokol, ako písomný dokument, musí obsahovať nasledovné časti: opis prostredia a zdrojov, v ktorom boli akceptačné testy realizované; opis vykonaných akceptačných testov a opis aktivity používateľov; opis výsledkov jednotlivých testov a ich zhodnotenie; zhodnotenie výsledkov merania kritických atribútov systému; podrobný opis testov, ktoré preukázali chyby systému, zhodnotenie chýb a spôsob ich odstránenia; celkové zhodnotenie splnenia alebo nesplnenia akceptačných kritérií pre systém Protokol o zaškolení používateľov systému Dokument vypracováva dodávateľ/riešiteľ systému IS. Dokument schvaľuje zadávateľ IS/podnik, po overení používateľmi a prevádzkovateľom systému. Dokument obsahuje nasledovné časti: zoznam použitých materiálov na školenie - jedná sa predovšetkým o používateľské príručky; opis rozsahu a obsahu školenia, prípadne školení; zhodnotenie výsledkov skúšobnej prevádzky systému používateľmi; zoznam účastníkov školenia. 147

148 Odovzdávací a preberací protokol Odovzdávací a preberací protokol je dokument, ktorým sa odovzdáva IS zadávateľovi IS. Dokument vypracováva riešiteľ IS v spolupráci zo zadávateľom IS. Dokument obsahuje nasledovné časti: miesto, termín a osoby zúčastnené na preberacom konaní; predmet dodávky zoznam produktov a služieb dodávaných riešiteľom; zoznam magnetických a optických médií a uloženie programových produktov na nich; identifikované chyby počas preberania, spôsob a postupnosť ich odstraňovania; spôsob údržby systému z hľadiska dodávateľa, ak nebol spôsob údržby systému dohodnutý v uzavretej zmluve; pravidlá pre inštalovanie častí IS na pracoviskách podniku; záručná doba, ak nebola dohodnutá v uzavretej zmluve; zodpovednosť za škody, ak nebola dohodnutá v uzavretej zmluve Podmienky začatia a ukončenia fázy Fáza Akceptačné testovanie začína v plánovanom alebo inak dohodnutom termíne za predpokladu úspešného ukončenia Integračného testovania. Fáza Akceptačné testovanie končí vykonaním všetkých činností, vrátane vystavenia a podpísania preberacieho protokolu, ktorým zadávateľ IS preberá IS do rutinnej prevádzky Zodpovednosť za realizáciu fázy V zásade platí, že zodpovednosť za realizáciu tejto fázy má vecne príslušný útvar podniku budujúceho nový IS. Najčastejšie je to útvar, ktorý bude prevádzkovateľom nového IS. 148

149 12 Prevádzka a údržba IS 12.1 Rámcový opis fázy Cieľom fázy prevádzky a údržby systému je zabezpečiť každodennú prevádzku IS, jeho ďalší rozvoj a prispôsobovanie meniacim sa požiadavkám používateľov a prevádzkovateľa. Súčasťou etapy je aj zabezpečovanie primeranej ochrany IS pri prevádzke Detailný opis fázy Zodpovednosť za prevádzku, údržbu a servis IS preberá prevádzkovateľ IS. Údržbu IS je možné zabezpečovať dodávateľským spôsobom, vlastnými kapacitami prevádzkovateľa systému alebo kombinovaným spôsobom, a to v závislosti od kapacitných možnosti spoločnosti. Pri údržbe a servise systému externým dodávateľom sa obvykle touto úlohou poveruje pôvodný riešiteľ systému. Popri zabezpečovaní samotnej prevádzky IS, ktorá je kľúčovou činnosťou v tejto fáze životného cyklu IS a poskytovaní informačných služieb pre používateľov IS (help desk), ďalšími činnosťami fázy prevádzky a údržby okrem iných sú: monitorovanie prevádzky a odstraňovanie hlásených porúch a chýb systému; evidencia požiadaviek na zmeny v IS a v dokumentácii, riadenie zmien v IS; správa konfigurácií IS, a systémovej a používateľskej dokumentácie IS; zabezpečenie ochrany a bezpečnosti IS pri prevádzke. V úvode tejto fázy prevádzkovateľ IS pripraví záväzné predpisy pre riadenie zmien, správu konfigurácií a zabezpečenie ochrany a bezpečnosti prevádzkovaného IS, prípadne využije už existujúce predpisy alebo vykoná ich nutnú úpravu. Samotná fáza prevádzky a údržby IS má kontinuálny charakter. Pri realizácii sa vychádza z platného harmonogramu procesov spracúvania dát a zo stanovených metodických predpisov Prevádzka IS Prevádzku IS zabezpečuje vecne príslušný útvar spoločnosti. Prevádzka IS môže byť taktiež rozdelená medzi viaceré útvary spoločnosti. 149

150 Typickými, relatívne samostatnými prevádzkovateľmi častí IS sú: CVS, ZVS, účelové organizačné jednotky, pracoviská kontaktu s klientmi, správa sietí, dohľadové pracovisko, administratívne centrum bezpečnosti IS a iné. Jednotlivé pracoviská zabezpečujú rutinnú prevádzku v dohodnutom režime. Podľa potreby používajú Chybové hlásenia a Požiadavky na zmeny prevádzkovaného IS Riadenie zmien Prevádzkovateľ stanovuje zásady a pravidlá pre riadenie zmien v prevádzkovanom IS. Počas prevádzky IS je úlohou prevádzkovateľa evidovať, vyhodnocovať a realizovať požiadavky používateľov na vykonanie zmien v prevádzkovanom IS. Požiadavky na zmeny je možné rozdeliť do nasledovných kategórií: požiadavky na odstránenie identifikovanej chyby v prevádzkovanom systéme; požiadavky na vylepšovanie vlastností IS, vyplývajúce zo skúseností s jeho používaním; požiadavky na zmenu (reimplementáciu) modulov s veľkou chybovosťou a obtiažnou údržbou; požiadavky na prispôsobovanie IS zmeneným okolitým podmienkam, resp. zmenám postupov spracovania informácii vo vnútri organizácie. Na monitorovanie prevádzky riadenie zmien prevádzkovaného IS sa zriaďuje tzv. Dohľadové pracovisko, ktoré monitoruje stav prevádzky IS. Na toto pracovisko sú používateľmi zasielané všetky hlásenia súvisiace s poruchami IS, ako aj požiadavkami na zmeny prevádzkovaného IS. Pracovisko organizuje posúdenie hlásení tak HW, ako aj SW charakteru a podľa vyjadrenia metodikov k hlásenej poruche alebo zmene ďalej organizuje nadväzujúce servisné činnosti. Okrem toho pracovisko môže zabezpečovať činnosti súvisiace s inštaláciou nových verzií SW na výkonné pracoviská, ako aj činnosti súvisiace s likvidáciou verziou SW, ktorá je vyradená z rutinného používania Správa konfigurácií a systémovej dokumentácie Výsledkom realizovaných zmien sú nové verzie (konfigurácie) prevádzkovaného IS a príslušnej systémovej, resp. používateľskej dokumentácie. Pravidlá a postupy pre správu konfigurácií IS (periodicitu vytvárania nových verzií, postup pri vytváraní, uvoľňovaní do prevádzky, resp. sťahovaní z prevádzky, atď.) stanovuje prevádzkovateľ IS pri zavádzaní systému do prevádzky. Východiskom pre tento dokument sú zásady a pravidlá vyplývajúce z informačnej politiky spoločnosti. 150

151 Zabezpečenie ochrany a bezpečnosti IS Z hľadiska zaistenia bezpečnosti IS nasledovné procesy: v tejto fáze životného cyklu by mali prebiehať a) Manažment konfigurácií a zmien, b) Kapacitný manažment, c) Udržiavanie prevádzkovej dokumentácie, d) Údržba, e) Monitorovanie bezpečnostne relevantných zmien, f) Auditné záznamy a protokolovanie, g) Bezpečnostné testovanie, h) Riadenie médií, i) Oddelenie povinností, j) Správne používanie softvéru, k) Riadenie zmien softvéru, l) Archivácia a zálohovanie dát, m) Ošetrovanie bezpečnostných incidentov, n) Interný audit bezpečnosti, o) Externý audit bezpečnosti, p) Zaistenie bezpečnosti pri likvidácii IS. Ďalší opis týchto činnosti je uvedený v kapitole Postup činností v rámci tejto fázy životného cyklu IS je možné zjednodušenie vyjadriť diagramom postupu prác znázorneným obrázkom č

152 Obrázok č Postup činností v rámci fázy Prevádzka a údržba IS K Špecifikácia IS Vypracovanie zásad a postupov pre Činnosť Help-desku Riadenie zmien Monitorovanie systému Riadenie bezpečnosti Interné normy PREVÁDZKA A ÚDRŽBA IS Hlásenia Hlásenia Hlásenia SPRÁVA BEZPEČNOSTI POČAS PREVÁDZKY a) Manažment konfigurácií a zmien b) Kapacitný manažment c) Udržiavanie prevádzkovej dokumentácie d) Údržba e) Monitorovanie bezpečnostne relevantných zmien f) Auditné záznamy a protokolovanie g) Bezpečnostné testovanie h) Riadenie médií i) Oddelenie povinností j) Správne používanie softvéru k) Riadenie zmien softvéru l) Archivácia a zálohovanie dát m) Ošetrovanie bezpečnostných incidentov n) Interný audit bezpečnosti o) Externý audit bezpečnosti p) Zaistenie bezpečnosti pri likvidácii IS. Požiadavky na zmeny Protokoly nie Ukonèenie prevádzky IS? K 152

153 12.3 Dokumenty vznikajúce v rámci fázy Pri príprave spoločnosti na prevádzku a údržbu IS vznikajú okrem iných, nasledovné druhy dokumentov : Zásady a postupy pri riadení zmien v IS, Zásady a postupy pri správe konfigurácií IS, Zásady a postupy pri zabezpečovaní ochrany a bezpečnosti prevádzky IS, Zásady monitorovania výkonnosti a spoľahlivosti IS. Zásady a postupy platné počas prevádzky IS sú obsiahnuté vo vydaných interných normách podniku. V rámci rutinnej prevádzky vznikajú okrem iných, nasledovné druhy dokumentov : Hlásenie o výskyte poruchy alebo chyby IS, Hlásenie o podozrivej udalosti alebo bezpečnostnom incidente, Požiadavky na zmeny funkčností IS alebo zmeny HW platformy IS Požiadavka na zrušenie alebo pridanie používateľa, Požiadavka na zmenu prístupových práv používateľov a ďalšie Podmienky začatia a ukončenia fázy Podmienkou pre začatie tejto fázy životného cyklu IS je ukončenie fázy akceptačného testovania IS a podpísanie Protokolu, ktorým sa IS preberá do rutinnej prevádzky. Fáza prevádzky a údržby IS trvá počas celej životnosti predmetného IS Zodpovednosť za realizáciu fázy Zodpovednosť za realizáciu fázy má Prevádzkovateľ systému. 153

154 13 Riadenie kvality IS S rozvojom informatizácie spoločnosti vzniká a využíva sa veľké množstvo softvérových produktov. Pre každý z takýchto produktov je potrebné počas ich vzniku a využívania zabezpečiť riadenie kvality. Cieľom tejto časti skrípt je poskytnúť informáciu o riadení kvality softvéru počas životného cyklu, vychádzajúc z noriem ISO Základné normy pre riadenie kvality V Európe platné normy pre riadenie kvality sa nachádzajú najmä v sade noriem označovaných ako ISO V nasledujúcej časti skrípt vychádzame z: normy STN ISO 9001:2000 Systém manažérstva kvality. Požiadavky, novej normy STN ISO Návod na aplikáciu normy ISO 9001:2000 na počítačový softvér, vydanej v roku ISO/IEC Poslaním tejto normy je poskytnúť návod na aplikáciu normy ISO 9001:2000 pri zaobstarávaní, dodávaní, vývoji a údržbe počítačového softvéru. Norma identifikuje položky, ktorými sa treba zaoberať. Nezávisí o technológie, modelov životného cyklu, vývojových procesov, postupnosti činností ani organizačnej štruktúry organizácie. Obsah normy je rámcovo znázornený obrázkom č Všetky požiadavky normy sú všeobecne použiteľné vo všetkých organizáciách bez ohľadu na druh, veľkosť a poskytované produkty. Aplikácia normy sa týka softvéru, ktorý: o o o o o je súčasťou obchodnej zmluvy s inou organizáciou, je produktom pripraveným na trh, sa používa na podporu procesov v organizácií, je zabudovaný do hardvéru týka sa softvérových služieb. 154

155 Kapitoly 4,5 a 6 a časti kapitoly 8 z normy ISO 9001:2000 sa aplikujú na globálnej úrovni organizácie aj keď majú vplyv aj na úroveň produktu. Vývoj každého produktu môže potrebovať, aby požiadavky na systém riadenia kvality boli prispôsobené špecifickým podmienkam produktu. Organizácie so systémami riadenia kvality pre vývoj, prevádzku a udržiavanie softvéru si na podporu alebo doplnenie procesného modelu vytváraného podľa ISO 9001 vybrať používanie noriem ISO/IEC a/alebo ISO/IEC 12207:1995/Amd1:2002. Obrázok č Rámcový obsah normy ISO/IEC Rámcový obsah normy ISO/IEC Predhovor 1. Predmet normy 2. Normatívne odkazy 3. Termíny a definície 4. Všeobecné požiadavky 5. Zodpovednosť manažmentu 6. Manažérstvo zdrojov 7. Realizácia produktu 8. Meranie, analýza a zlepšovanie 9. Príloha A (informatívna) - Dodatočný návod na zavádzanie normy ISO 9001:2000, ktorý ponúkajú normy ISO/IEC JTC/ SC7 a ISO/TC Príloha B (informatívna) Plánovanie v normách ISO/IEC a ISO/IEC Literatúra Ďalej uvádzame výber informácií týkajúci sa odporúčaného spôsobu plnenia požiadaviek certifikačnej normy ISO 9001:2000, v prípade tvorby a používania softvéru. Slovo organizácia vyjadruje tvorcu a/alebo dodávateľa softvéru. 155

156 13.3 Systém manažérstva kvality Požiadavka podľa ISO 9001:2000 Organizácia musí vytvárať, zdokumentovať, zaviesť a udržiavať systém manažérstva kvality a trvalo zlepšovať jeho efektívnosť v súlade s požiadavkami certifikačnej normy Návod pre oblasť softvérových produktov Pri plnení požiadaviek normy ISO 9001 je potrebné: a) Proces identifikácia a aplikácie o Organizácia musí identifikovať aj procesy vývoja, prevádzkovania a udržiavania softvéru b) Postupnosť procesov a ich interakcia a) Organizácia má definovať aj postup a interakciu procesov: 1. V modeloch životného cyklu vývoja softvéru, ak je vodopádový model, inkrementálny model a evolučný model 2. Pri plánovaní kvality a vývoja, ktoré majú vychádzať z modelu životného cyklu Požiadavky na dokumentáciu Požiadavka podľa ISO 9001:2000 Dokumentácia systému manažérstva kvality musí obsahovať: a) zdokumentované vyhlásenia politiky kvality a cieľov kvality; b) príručku kvality; c) zdokumentované postupy požadované certifikačnou normou; d) dokumenty potrebné v organizácii na zaistenie efektívneho plánovania, prevádzky a riadenia jej procesov e) záznamy vyžadované normou Návod pre oblasť softvérových produktov Dokumenty na efektívne plánovanie, prevádzku a riadenie procesov softvéru môžu zahŕňať: 1. Opisy identifikovaných procesov, 2. Opisy použitých procedurálnych šablón a inštrukcií, 156

157 3. Opisy použitých modelov životného cyklu, 4. Opisy nástrojov, techník, technológií a metód, 5. Technické aspekty, ako sú normy alebo dokumenty návodov na programovanie, navrhovanie, vývoj a testovanie Plánovanie systému riadenia kvality Požiadavka podľa ISO 9001:2000 Vrcholový manažment organizácie musí zaistiť, aby sa: a) naplánoval systém riadenia kvality s cieľom splniť požiadavky uvedené v kapitole 4.1 normy, ako aj ciele kvality, b) zachovala integrita systému manažérstva kvality, ak sa plánujú a zavedú jeho zmeny Návod pre oblasť softvérových produktov Plánovanie kvality môže prebiehať na organizačnej úrovni projektu alebo produktu. Plánovanie QMS na organizačnej úrovni môže zahŕňať: a) definovanie vhodných modelov životného cyklu softvéru, ktoré sa majú využívať pre rôzne typy projektov zabezpečovaných organizáciou, vrátane postupov, pomocou ktorých organizácia zvyčajne zavádza procesy životného cyklu softvéru; b) definovanie pracovných produktov (work products) vývoja softvéru, ako sú dokumenty s požiadavkami na softvér, dokumenty architektúry, dokumenty podrobného návrhu, kód programu a dokumentácia pre požívateľa softvéru; c) definovanie obsahu plánov riadenia softvéru, ako sú: o plány riadenia softvérového projektu, o plány projektu riadenia softvérovej konfigurácie, o plány verifikácie a validácie softvéru, o plány zabezpečenia kvality softvéru o a plány školení; d) definovanie spôsobov, ako sa metódy softvérového inžinierstva prispôsobia projektom organizácie počas životného cyklu; e) identifikáciu nástrojov a prostredia pre vývoj, prevádzku alebo udržiavanie softvéru; f) špecifikáciu dohôd pri používaní programovacích jazykov, napr. pravidiel programovania, softvérových knižníc a štruktúr g) identifikáciu akéhokoľvek opakovaného použitia softvéru. Predstaviteľ manažmentu organizácie má zvážiť akúkoľvek zmenu životného cyklu softvéru, ktorá môže ovplyvniť QMS a má zabezpečiť, aby tieto zmeny neviedli k ústupkom pri kontrolách využívaného QMS. 157

158 13.6 Preskúmavanie systému manažmentom Požiadavka podľa ISO 9001:2000 Vrcholový manažment musí v plánovaných intervaloch preskúmavať QMS organizácie, aby sa zaistila jeho trvalá vhodnosť, primeranosť a efektívnosť. Toto preskúmavanie musí zahŕňať hodnotenie príležitostí na zlepšovanie a potrebu zmien QMS vrátane politiky kvality a cieľov kvality. Vstup do preskúmania musí obsahovať informácie o: a) výsledkoch auditu; b) spätných informáciách od zákazníka; c) výkonnosti procesu a zhode produktu; d) stave preventívnych a nápravných opatrení; e) následných činnostiach po predchádzajúcom preskúmaní; f) zmenách, ktoré by mohli ovplyvniť QMS; g) odporúčaniach na zlepšenie Návod pre oblasť softvérových produktov Z hľadiska vstupov do preskúmania QMS organizácie platí, že informácie týkajúce sa výkonnosti procesov sa v prípade softvérového procesu môžu stotožniť s výstupmi posúdenia softvérového procesu. Jednou z možností, ako merať zhodu produktu je vykonať hodnotenie softvérového produktu. Výstupy z takéhoto hodnotenia softvérového produktu sú vstupmi do preskúmavania systému riadenia kvality manažmentom organizácie Kompetentnosť, povedomie a príprava pracovníkov Požiadavka podľa ISO 9001:2000 Organizácia musí: a) určiť potrebnú kompetentnosť pracovníkov, ktorí vykonávajú prácu ovplyvňujúcu kvalitu produktu; b) zabezpečiť prípravu alebo prijať opatrenia, ktoré uspokojujú tieto potreby; c) vyhodnocovať efektívnosť poskytovanej prípravy; d) zaistiť, aby si pracovníci uvedomovali závažnosť a dôležitosť svojich činností a svojho príspevku k dosahovaniu kvality; e) udržiavať primerané záznamy o vzdelaní, príprave, zručnosti a skúsenosti. 158

159 Návod pre oblasť softvérových produktov Potrebu prípravy pracovníkov je potrebné určiť s ohľadom na: o definované požiadavky, o metódy návrhu, o programovacie jazyky, o nástroje, o techniky o a počítačové prostriedky, ktoré sa majú používať pri vývoji a riadení softvérového produktu. Aby sa zaistili požiadavky na zdokonaľovanie zručnosti pracovníkov, majú sa technológie používané pri vývoji, prevádzkovaní a udržiavaní softvéru nepretržite monitorovať a hodnotiť. Vyhodnotenie efektívnosti prípravy možno robiť prostredníctvom merania produktu a procesov a identifikovaním oblastí zlepšovania výkonnosti pracovníkov Infraštruktúra Požiadavka podľa ISO 9001:2000 Organizácia musí určiť, poskytovať a udržiavať infraštruktúru potrebnú na dosahovanie zhody produktu s požiadavkami. Infraštruktúra napríklad zahŕňa: a) budovy, pracovný priestor a súvisiace vybavenie; b) pracovné zariadenia ( softvér a hardvér); c) podporné služby ( ako sú doprav a komunikácia) Návod pre oblasť softvérových produktov Infraštruktúra má zahŕňať hardvér, softvér, nástroje a zariadenia na vývoj, prevádzkovanie a udržiavanie softvéru. Infraštruktúra môže zahŕňať softvérové nástroje používané v procese návrhu a vývoja, vrátane: a) nástrojov používaných pri analýze, návrhu a vývoji, pri riadení konfigurácie, testovaní, pri riadení projektu, dokumentovaní, vytváraní alebo generovaní kódu; b) vývoja aplikácie a podporných činností; c) riadenia znalostí internetových a extranetových nástrojov; d) sieťových nástrojov, ako je ochrana, zálohovanie, ochrana pred vírusmi, FW; e) poradenského centra ( helpdesk) a nástrojov na udržiavanie; f) kontroly prístupov; g) softvérových knižníc; h) nástrojov riadenia prevádzky, ako je monitorovanie siete, riadenie systémov a riadenie procesu zálohovania. 159

160 Bez ohľadu na to, či sa tieto nástroje a techniky vyvíjajú interne alebo sa nakupujú, organizácia má posúdiť, či sú alebo nie sú vhodné na daný účel. Nástroje používané na implementáciu produktu, ako sú nástroje na analýzu, návrh a vývoj, kompilátory a assembléry, majú sa pred použitím posúdiť, schváliť a zaradiť do príslušnú úroveň kontroly riadenia konfigurácie. Rozsah používania nástrojov možno zdokumentovať primeraným návodom a ich používanie možno preskúmať s cieľom, či ich treba zlepšiť alebo aktualizovať Plánovanie realizácie produktu Požiadavka podľa ISO 9001:2000 Organizácia musí plánovať a vypracovať procesy potrebné na realizáciu produktu. Plánovanie realizácie produktu musí byť v súlade s požiadavkami ďalších procesov QMS. Podľa potreby organizácia musí určiť: a) ciele kvality a požiadavky na produkt; b) potrebu definovať procesy a dokumentáciu a poskytovať zdroje špecifické pre produkt; c) požadovanú verifikáciu, validáciu, monitorovanie, kontrolu a skúšobné činnosti špecifické pre produkt, ako aj kritériá prijatia; d) záznamy nevyhnutné na poskytovanie dôkazu, že procesy realizácie a finálny produkt spĺňajú požiadavky. Výstup z tohto plánovania musí mať formu, ktorá zodpovedá metóde činnosti organizácie. Dokument ktorý špecifikuje procesy QMS a zdroje, ktoré sa majú použiť na konkrétny produkt, projekt alebo zmluvu sa môže označovať ako Plán kvality Návod pre oblasť softvérových produktov Životný cyklus softvéru Procesy, činnosti a úlohy sa majú plánovať a realizovať pomocou modelov životného cyklu, ktoré zodpovedajú charakteru softvérového produktu pri zohľadnení jeho zložitosti, bezpečnosti, rizika a integrity. Plánovanie vývoja softvéru má vyústiť do definície toho, aké produkty sa majú vytvoriť, kto ich má vytvoriť, a kedy sa majú vytvoriť. 160

161 Plánovanie kvality na úrovni projektu/produktu má vyústiť do opisu, ako sa má produkt vyvíjať, posudzovať alebo udržiavať Plánovanie kvality Plánovanie kvality dáva prostriedky na aplikovanie procesov riadenia kvality na konkrétny projekt alebo produkt, prípadne zmluvu. Plán kvalitu sa má v priebehu návrhu a vývoja opakovane preverovať a pri začatí novej etapy sa majú definovať položky, ktoré sa jej týkajú. Plán kvality by mal byť preskúmavaný a odsúhlasovaný všetkými organizáciami zainteresovanými na jeho implementácii. Plánovanie kvality softvéru na úrovni projektu má zahŕňať: a) plány vývoja alebo odkazy na ne; b) požiadavky na kvalitu týkajúce sa produktu a/alebo procesov; c) prispôsobenie QMS osobitným predpisom súvisiacim s tvorbou softvérového produktu; d) postupy a inštrukcie špecifické pre projekt, ako sú podrobné plány testov, postupy testovania komponentu, integrity, systému a akceptácie; e) metódy, model životného cyklu, nástroje, dohody o spôsobe používania programovacieho jazyka, knižnice, štruktúry a ďalšie položky použiteľné v projekte; f) kritériá začatia a skončenia každej etapy; g) druhy preskúmaní a ďalšie verifikačné a validačné činnosti, ktoré sa majú vykonávať; h) postupy riadenia konfigurácie; i) monitorovacia a meracia činnosť; j) pracovníka zodpovedného za odsúhlasovanie výstupov procesu pre nasledujúce použitie; k) potrebu prípravy na používanie nástrojov a techník, harmonogram prípravy a požadovaná zručnosť; l) záznamy, ktoré sa majú udržiavať. Plánovanie kvality aj keď obmedzené je osobitne užitočné pri vyjasňovaní kvality softvéru, ktorý je určený na obmedzené použitie, napríklad demonštračné prototypy. Prototypy by sa mal skúšať úmerne ich čelu používaniu. 161

162 13.10 Určenie požiadaviek týkajúcich sa produktu Požiadavka podľa ISO 9001:2000 Organizácia musí určiť: a) požiadavky špecifikované zákazníkom vrátane požiadaviek na dodávanie a činnosti po dodaní produktu; b) požiadavky nešpecifikované zákazníkom, ale nevyhnutné na osobitné alebo zamýšľané použitie, ak sú známe; c) požiadavky predpisov a legislatívne požiadavky týkajúce sa produktu; d) akékoľvek iné požiadavky Návod pre oblasť softvérových produktov Softvér možno vyvinúť ako súčasť zmluvy, ako produkt vhodný na trh, ako softvér zabudovaný do HW alebo ako softvér na podporu podnikateľských procesov organizácie. Určovanie požiadaviek sa týka všetkých uvedených okolností. Osobitné opatrenia musia zahŕňať: a) vytvorenie ďalej uvedených podkladov na vypracovanie požiadaviek: 1. metód odsúhlasovania požiadaviek, autorizácie a sledovania zmien najmä počas iteratívneho vývoja; 2. metód hodnotenia prototypov alebo demonštrácií, ak sa využíva; 3. metód zaznamenávania a preskúmavania výsledkov diskusie so všetkými zainteresovanými stranami; b) vypracovanie požiadaviek v úzkej spolupráci so zákazníkom alebo používateľmi a vynaloženie úsilia na zabránenie nedorozumení, napríklad poskytovaním definícií termínov a vysvetlením podstaty požiadaviek; c) získanie súhlasu zákazníka s požiadavkami; d) vypracovanie metódy sledovania požiadaviek k finálnemu produktu ( matica sledovateľnosti požiadaviek). Požiadavky môže poskytovať zákazník, môže ich vypracovať organizácia alebo sa môžu vypracovať spoločne. Ak sa požiadavky poskytnú a odsúhlasia v tvare špecifikácie systému, majú byť k dispozícií metódy, ktoré ich zabudujú do HW a SW položiek systému s príslušnými rozhraniami. Je potrebné sledovať zmeny a premietať ich po odsúhlasení do riešenia. 162

163 Požiadavky môžu zahŕňať potrebu zohľadniť prevádzkové prostredie, môžu zahŕňať tieto charakteristiky: funkčnosť, spoľahlivosť, použiteľnosť, výkonnosť, udržiavateľnosť, prenositeľnosť. ochrana a bezpečnosť. zákonné požiadavky. Niektoré požiadavky môžu byť označené ako kritické. Ak softvérový produkt má rozhranie s ďalšími produktmi, musia sa čo najvýstižnejšie špecifikovať rozhrania medzi vyvíjaným softvérom a inými softvérmi a to priamo alebo odkazmi na požiadavky. Požiadavky je treba vyjadriť v jasných a jednoznačných termínoch, čo uľahčuje validáciu pri akceptácií produktu. Požiadavky musia byť sledovateľné počas celého životného cyklu softvéru Preskúmavanie požiadaviek na produkt Požiadavka podľa ISO 9001:2000 Organizácia musí preskúmať požiadavky týkajúce sa produktu. Toto preskúmanie sa musí vykonať pred prijatím záväzku na dodanie produktu zákazníkovi ( napr. pred rozoslaním ponúk, podpísaním zmluvy, akceptovaním zmluvy alebo objednávky) a musí sa zaistiť, že: a) sa definovali požiadavky na produkt; b) sa vyriešili požiadavky zmluvy alebo objednávky odlišné od tých, ktoré sa určili skôr; c) organizácia je schopná splniť definované požiadavky. Musia sa uchovávať záznamy z preskúmavania. Ak zákazník neposkytne zdokumentované vyjadrenie alebo zdokumentovanú požiadavku, organizácia musí požiadavky pred prijatím odsúhlasiť. Ak sa požiadavky na produkt zmenili, organizácia musí zaistiť, aby sa príslušné dokumenty zmenili a aby príslušní pracovníci boli upovedomení o zmenených požiadavkách. 163

164 Návod pre oblasť softvérových produktov Záujmy organizácie Počas preskúmania ponúk na dodávku softvéru, zmlúv alebo objednávok organizáciou môžu byť dôležité najmä tieto skutočnosti: a) možnosť splnenia a validácie požiadaviek a charakteristík produktu, vrátane identifikácie požadovaných charakteristík softvéru ako sú funkčnosť, spoľahlivosť, bezpečnosť a ďalšie. b) normy návrhu a vývoja softvéru a postupy, ktoré sa majú použiť, c) identifikácia vybavenia, nástrojov, softvérových položiek a dát, ktoré má poskytnúť zákazník, definícia a dokumentácia metód na posúdenie ich vhodnosti na používanie, d) OS alebo HW platforma, e) dohoda o riedení externých rozhraní pomocou softvérového produktu, f) požiadavky na replikáciu a distribúciu, g) skutočnosti týkajúce sa zákazníka, h) skutočnosti týkajúce sa riadenia, zváženie rizík riadenia, zodpovednosť organizácie za dodávateľské práce, harmonogram postupu, technických preskúmaní a výstupov, požiadavky na inštaláciu, udržiavanie a podporu, požiadavky na dostupnosť zdrojov, i) skutočnosti týkajúce sa práva, ochrany a dôvernosti práva duševného vlastníctva, patentové práva, autorské práva, starostlivosť o master copy produktu, určenie lehôt záruk, záruky a pokuty týkajúce sa neplnenia zmluvy Riziká Pri preskúmavaní požiadaviek týkajúcich sa produktu možno zvažovať tieto riziká: a) hľadisko kritickosti, bezpečnosti a ochrany b) spôsobilosť a skúsenosť organizácie a jej subdodávateľov, c) adekvátnosť odhadov potrebných zdrojov a doby trvania činností, d) geografické rozptyly organizácie, zákazníkov, používateľov a dodávateľov, e) špičkové technické novinky a ich použiteľnosť pre projekt, f) kvalita a dostupnosť softvéru a nástrojov, g) rozlišovacia schopnosť, presnosť a stabilita požiadaviek zákazníka a externých rozhraní. Nemá sa zabúdať na posudzovanie prípadných zmien uvádzaných faktorov na projekt. 164

165 Predstaviteľ zákazníka Zákazník musí mať zmluvnú zodpovednosť. Týka sa to najmä nevyhnutnej spolupráce s organizáciou dodávajúcou softvér, poskytovania informácií v požadovanom čase a prijímania opatrení. Predstaviteľ zákazníka musí byť zástupcom tak používateľov, ako aj manažmentu a musí mať právomoc zaoberať sa predmetom zmluvy s dodávateľskou organizáciou, čo zahŕňa najmä: preberania odovzdávaných častí softvéru, dát, nástrojov a vybavenia, organizovania kontaktov na zástupcov útvarov, prípadne na iné spoločnosti. Preskúmavanie môžu vykonávať tak interné, ako aj externé organizácie Komunikácia so zákazníkom Požiadavka podľa ISO 9001:2000 Organizácia musí určiť a zaviesť efektívne opatrenia umožňujúce komunikáciu so zákazníkmi túkajúcu sa: a) informácií o produkte, b) vybavovania dotazov, zmlúv alebo objednávok vrátane zmien, c) spätnej väzby od zákazníka vrátane jeho sťažností Návod pre oblasť softvérových produktov Metóda komunikácie sa môže v prípade softvéru meniť podľa typu zmluvy a rozsahu zmluvy na vývoj, prevádzku a udržiavanie softvéru, či celého IS Komunikácia so zákazníkom počas vývoja Preskúmania, ktoré vykonáva organizácia spoločne so zákazníkom možno naplánovať v pravidelných intervaloch alebo vo významných bodoch projektu, aby sa zahrnuli najmä tieto aspekty: a) informácie o produkte 1. Plány vývoja, 2. zhoda výstupov (dokumentov) s odsúhlasenými požiadavkami, 3. výsledkov akceptačných testov, b) otázky, dohody a zmeny 1. postupy činností týkajúcich sa používateľov systému, ako aj nasadenia produktu a príprava pracovníkov, 2. pokrok vo vývojových prácach, 3. pokrok v prácach zabezpečovaných zákazníkom, 4. riešenie otázok rizika, problémov a zmien 165

166 5. metód pre doručovanie informácií o súčasných a plánovaných budúcich zmenách Komunikácia so zákazníkom počas prevádzky a udržiavania softvéru Zdroje informácií, ktoré zahŕňajú komunikáciu so zákazníkom počas prevádzkovania a údržby softvéru môžu zhŕňať najmä: a) informácie o produkte 1. helpdesk a príručky pre používateľov 2. opisy nových vydaní a aktualizácií 3. webové stránky o produkte b) otázky, dohody a zmeny 1. priebeh dodávania výrobku alebo služby 2. ošetrovanie rizík týkajúcich sa výrobky alebo služby a ich zmien c) spätnú väzbu zákazníka 1. zriadenie a fungovanie helpdesku 2. priebeh vybavovania sťažností zákazníka 3. dotazníky, požívateľské skupiny a neformálne stretnutia Plánovanie návrhu a vývoja Požiadavka podľa ISO 9001:2000 Organizácia musí plánovať a riadiť návrh a vývoj produktu. Počas plánovania návrhu a vývoja musí organizácia určiť: a) etapy návrhu a vývoja, b) preskúmavanie, verifikáciu a validáciu patriace ku každej etape návrhu a vývoja, c) zodpovednosť a právomoc pri návrhu a vývoji. Organizácia musí riadiť rozhrania medzi skupinami zainteresovanými na návrhu a vývoji, aby sa zaistila efektívna komunikácia a jasné priradenie zodpovednosti. Plánovanie výstupu sa pri napredovaní návrhu a vývoja musí podľa potreby aktualizovať Návod pre oblasť softvérových produktov Plánovanie návrhu a vývoja Návrh a vývoj sa musí konať disciplinovaným spôsobom aby sa zabránilo výskytu problémov alebo aby sa výskyt problémov minimalizoval. Takáto postup znižuje závislosť od verifikácie a validácie ako výhradných metód identifikácie problémov. Preto organizácia 166

167 sa má ubezpečiť, či softvérové produkty sa vyvíjajú v zhode so špecifikovanými požiadavkami a b v s súlade s plánom návrhu a vývoja a plánom kvality. Plánovanie návrhu a vývoja má podľa potreby zahŕňať najmä tieto položky: a) činnosti vyplývajúce z analýzy požiadaviek, z návrhu a vývoja, z programovania, integrácie, testovania, inštalácie a podpory a preberania softvérových produktov. Patrí sem aj identifikácia alebo odkaz na: b) plánovanie riadenia produktu a poskytovania služieb, c) organizáciu zdrojov na projekt vrátane zloženia tímu, zodpovednosti, využitia dodávateľov a materiálnych zdrojov, ktoré sa majú použiť, d) organizačné a technické rozhrania medzi rôznymi jednotlivcami a lebo skupinami, ako sú čiastkové projektové tímy, dodávatelia, partneri, používatelia, predstavitelia zákazníka vrátane manažéra pre kvalitu e) analýza možných rizík, predpokladov, závislostí a problémov súvisiacich s návrhom a vývojom, f) harmonogram g) identifikáciu h) identifikáciu súvisiaceho plánovania týkajúceho sa takých oblastí ako sú kvalita, manažérske riziko, riadenie konfigurácie, riadenie dodávok, integrácia, riadenie procesu uvoľňovania, inštalácia, príprava pracovníkov, migrácia dát, udržiavanie, opakované používanie, komunikácia a meranie i) riadenie dokumentácie vrátane archívu. Ak je to potrebné plány sa maj meniť Preskúmavanie, verifikácia a validácia Preskúmavanie, verifikáciu a validáciu možno v praxi ich možno nahradiť dohodami o úrovni poskytovaných služieb alebo postupmi udržiavania Rozohrania V pláne návrhu a vývoja dodávateľ má jasne definovať hranice zodpovednosti za každú časť softvéru a spôsob ako sa medzi jednotlivými stranami budú prenášať technické informácie. Nesmie sa zabúdať ani na iné zúčastnené strany ako sú zástupcovia iných útvarov zákazníka či dodávatelia HW, dodávatelia služieb, atď Vstupy do návrhu a vývoja Požiadavka podľa ISO 9001:2000 Musia sa určiť vstupy týkajúce sa požiadaviek na návrh produktu a musia sa udržiavať záznamy. 167

168 Vstupy by mali obsahovať najmä: a) požiadavky na funkčnosť a výkonnosť, b) použiteľné požiadavky vyplývajúce z predpisov a legislatívne požiadavky c) poznatky odvodené z predchádzajúcich podobných návrhov d) ďalšie požiadavky závažné pre návrh a vývoj. Musí sa preskúmať primeranosť týchto vstupov. Požiadavky musia byť jednoznačné a navzájom nekonfliktné Návod pre oblasť softvérových produktov V návrhu architektúry systému sa HW, SW komponentom a ručnej obsluhe priradia systémové požiadavky. Vstup do návrhu a vývoja možno odvodiť od požadovaných charakteristík SW alebo ich možno určiť na základe tvorby prototypu. Vstup je možné určiť aj na základe požiadaviek na zmenu návrhu vychádzajúcich z predchádzajúcich etáp modelu SW v rámci iteratívneho vývoja. Pri kontrole vstupov, ktorá sa často vykonáva v súčinnosti so zákazníkom, treba skontrolovať, či: a) nie sú nejasné a rozporné, b) neobsahujú nedôsledné alebo neúplné informácie alebo nevykonateľné požiadavky, c) neobsahujú nereálne špecifikácie výkonnosti, d) neobsahujú požiadavky, ktoré nemožno verifikovať alebo validovať, e) nechýbajú nevyslovené predpoklady alebo požiadavky, f) neobsahujú nepresný opis prostredia a činnosti používateľa, g) nechýbajú rozhodnutia týkajúce sa návrhu a vývoja, h) sa nezabudlo na kľúčové ukazovatele výkonnosti Výstupy z návrhu a vývoja Požiadavka podľa ISO 9001:2000 Výstupy z návrhu a vývoja musia mať formu, ktorá umožňuje ich verifikáciu v porovnaní so vstupom do návrhu a vývoja a pred uvoľnením sa musia odsúhlasiť. Výstupy z návrhu a vývoja musia: a) spĺňať vstupné požiadavky do návrhu a vývoja, b) poskytovať primerané informácie pre nákup, výrobu a pre poskytovanie služieb, c) obsahovať alebo odkazovať na kritéria prijatia, d) špecifikovať charakteristiky produktu, ktoré sú dôležité pre jeho bezpečné a správne používanie. 168

169 Návod pre oblasť softvérových produktov Výstup z procesu návrhu a vývoja softvéru sa má definovať a zdokumentovať podľa predpísanej alebo vybranej metodiky. Výstup má byť úplný, presný a má byť v súlade s požiadavkami a možno ho vytvoriť pomocou nástrojov počítačového návrhu a vývoja. Výstupy možno vyjadriť v textovom tvare, pomocou diagramov alebo použitím symbolických modelových označení. Výstupy môžu obsahovať: a) špecifikácie návrhu, vývoja a testovania, b) modely údajov, c) pseudokód alebo zdrojový kód, d) návody na používanie, obslužnú dokumentáciu, materiál pre prípravu pracovníkov, dokumentáciu udržiavania, e) vyvinutý produkt, f) formálne metódy. AK sa ide cestou prototypu, výsledkom má byť dokumentáciu návrhu a vývoja. Majú sa definovať akceptačné kritériá výstupov z návrhu a vývoja, aby sa preukázalo, že vstupy do každej etapy sa odrážajú v správnych výstupoch. Nástroje pre špecifické zamýšľané použitie sa majú validovať Preskúmavanie návrhu a vývoja Požiadavka podľa ISO 9001:2000 V súlade s plánovanými opatreniami sa vo vhodných etapách musia vykonávať systematické preskúmania návrhu a vývoja, aby sa: a) vyhodnotila schopnosť výsledkov návrhu a vývoja plniť požiadavky, b) identifikovali akékoľvek problémy a navrhli sa nevyhnutné činnosti. účastníkmi takýchto preskúmaní musia byť predstavitelia funkcií, ktorých sa týkajú preskúmavané etapy návrhu a vývoja. Musia sa udržiavať záznamy o výsledkoch preskúmaní. a akýchkoľvek nutných činnostiach Návod pre oblasť softvérových produktov Stupeň oficiálnosti a dôkladnosti činností súvisiacich s procesmi preskúmavania má zodpovedať zložitosti produktu, požiadavkám na kvalitu a stupňu rizika súvisiaceho s konkrétnym použitím produktu. Organizácia musí vypracovať postupy, ktoré sa zaoberajú nedokonalosťami procesu a produktu alebo nezhodami odhalenými v priebehu týchto činností. 169

170 Odporúča sa, aby sa tieto postupy zdokumentovali. Pri preskúmavaní návrhu a vývoja sa majú zohľadniť také kritériá ako je realizovateľnosť, ochrana, bezpečnosť, pravidlá programovania a testovateľnosť. Preskúmavanie návrhu a vývoja sa má vykonávať v súlade s naplánovaným i opatreniami. K prvkom preskúmavania patria: a) čo a kedy sa má preskúmať, druh preskúmania, ako je predvedenie, oficiálny dôkaz správnosti, inšpekcia, rekapitulácia a spoločné preskúmanie, b) akých funkcií by sa mal týkať každý druh preskúmania, ak sa má zvolať porada o preskúmaní, ako sa bude organizovať a viesť c) aké záznamy sa majú vypracovať, napr. zápisnica, body rokovania, problémy, činnosti a stav po vykonaní, d) metódy monitorovania aplikácie pravidiel, praktík a konvencií zabezpečujúcich, že sa plnia požiadavky, e) čo treba urobiť pred realizáciou preskúmania, ak sú určené ciele, aký je program porady, aké dokumenty sa požadujú a aké sú úlohy pracovníkov pri preskúmaní, f) čo treba urobiť počas preskúmania vrátane techník, ktoré sa majú použiť, návodov pre všetkých zúčastnených, g) kritériá úspešnosti preskúmania, h) aké následné činnosti sa použijú na ubezpečenie toho, že prerokované otázky sa vyriešia. Ďalšie návrhy a vývojové činnosti by mali pokračovať až sa pochopia následky všetky zistených nedostatkov a posúdia sa a odsúhlasia sa riziká ďalšej činnosti Verifikácia návrhu a vývoja Požiadavka podľa ISO 9001:2000 Verifikácia návrhu a vývoja sa musí vykonávať v súlade s naplánovanými opatreniami., aby sa zaistilo, že výstupy návrhu a vývoja spĺňajú požiadavky vstupov návrhu a vývoja. Musia sa udržiavať záznamy o výsledkoch verifikácie Návod pre oblasť softvérových produktov Verifikácia softvéru s zameriava na poskytnutie ubezpečenia, že výstup z návrhu a vývoja softvérového produktu zodpovedá vstupným požiadavkám. Verifikácia sa vykonáva počas návrhu a vývoja. Môže zahŕňať preskúmanie výstupu napríklad kontrolami a rekapituláciou, analýzu, predvedenie vrátane prototypov, simuláciu alebo testy. 170

171 Výsledky verifikácie sa majú zaznamenávať a skontrolovať. Na akceptáciu systému možno používať len verifikované výstupy z návrhu a vývoja Validácia návrhu a vývoja Požiadavka podľa ISO 9001:2000 Validácia návrhu a vývoja sa musí vykonávať v súlade s plánovanými opatreniami., aby sa zaistilo, že výsledný produkt je schopný spĺňať požiadavky zamýšľaného používania, ak sú známe. AK je to možné a praktické, potom validácia sa musí dokončiť pred dodaním alebo zavedením produktu. Musia sa udržiavať záznamy o výsledkoch validácie Návod pre oblasť softvérových produktov Validácia Cieľom validácie softvéru je poskytnutie dôvery, že softvér bude spĺňať prevádzkové požiadavky. Kým sa produkt ponúkne zákazníkovi n akceptáciu, organizácia má validovať jeho prevádzku v súlade so zamýšľaným používaním v podmienkach podobným aplikačnému prostrediu. V priebehu validácie a pred vydaním referenčnej základne konfigurácie sa má podľa potreby vykonať audit alebo vyhodnotenie konfigurácie. Validácia má potvrdiť, že softvérový produkt je v súlade s hodnotenými požiadavkami alebo požiadavkami uvedenými v zmluve. Ak je validácia v prevádzkových podmienkach nepraktická, možno ju nahradiť analýzou, simuláciou alebo emuláciou Testovanie Validáciu možno často vykonať testovaním. Testovanie môže byť požadované od úrovne položky až po kompletný softvérový produkt. Existuje viacero prístupov k testovaniu. Plánovanie testovania má brať do úahy typy testov, ciele, postupnosť a rozsah testovania, prípady testovania, testovacie dáta a očakávané výsledky. 171

172 Špecifické testovanie softvéru zahŕňa zavedenie, zdokumentovanie, preskúmanie a realizáciu plánov pre: a) testy komponentov, b) testy integrácie a systémové testy, c) kvalifikačné testy, d) akceptačné testy. Regresné testy overujú, či vykonaná zmena neovplyvnila spôsobilosť softvéru. Akceptačné testy sú také testy, ktoré sa vykonávajú na osoh zákazníka s cieľom určiť prijateľnosť produktu. Testovacie prostredie a nástroje, ktoré sa majú použiť majú byť riadené a zaznamenané Riadenie zmien návrhu a vývoja Požiadavka podľa ISO 9001:2000 Musia sa identifikovať zmeny návrhu a vývoja a musia sa udržiavať súvisiace záznamy. Zmeny sa musia preskúmavať, podľa potreby verifikovať a validovať a pred zavedením odsúhlasiť. Preskúmavanie zmien musí zahŕňať aj vyhodnotenie účinku zmien na časti produktu a na už dodaný produkt. O preskúmaní zmien sa musia udržiavať záznamy Návod pre oblasť softvérových produktov V prostredí vývoja softvéru sa riadenie zmien návrhu a vývoja zvyčajne považuje za súčasť riadenia konfigurácie. Zmeny špecifikácie alebo komponentov softvéru majú zachovať primeraný súlad medzi požiadavkami, návrhmi, kódom, špecifikáciami testov, príručkami používateľa a ak je to potrebné aj ďalšími položkami Proces nakupovania Požiadavka podľa ISO 9001:2000 Organizácia musí zaistiť, aby nakupovaný produkt zodpovedal špecifikovaným požiadavkám na nákup. Druh a rozsah riadenia aplikovaný na dodávateľa a nakupovaný produkt musí závisieť od vplyvu nakupovaného produktu na následnú realizáciu produktu alebo na finálny produkt. 172

173 Organizácia musí hodnotiť a vyberať dodávateľov na základe ich schopnosti dodať produkt podľa požiadaviek organizácie. Musia sa definovať kritériá výberu, hodnotenia a prehodnotenia. Musia sa udržiavať s tým súvisiace záznamy Návod pre oblasť softvérových produktov Nakupované produkty Pre potreby nakupovania sa voľne dostupný softvér ( napr. vývojové nástroje s verejne dostupným kódom) považuje za nakúpený softvér. Pri vývoji, dodaní a udržiavaní softvérových produktov môžu nakupované produkty zahŕňať: a) komerčné softvérové produkty na sklade alebo voľne šírené produkty b) zákazkový softvér a služby, c) vývoj zabezpečovaný subdodávkami d) externe zabezpečované činnosti, e) nástroje určené na pomoc pri vývoji softvéru f) počítačový a komunikačný hardvér, g) komponenty, h) kurzy a materiály. Dôležitý je rozsah kontroly zo strany organizácie voči subdodávateľovi, pretože dôvera môže byť pre konečný úspech kritická. Dôležité je aj vyriešiť otázku trvalej spôsobilosti prevádzky nakúpeného softvéru vyplývajúce z neskorších vydaní a udržania licenčných práv Kontrola nakupovaných produktov Tam kde sa nakúpené komponenty stanú súčasťou dodávaného produktu, má sa kontrolovať ako časti prechádzajú návrhom a vývojom. Ak ide o subdodávku časti softvéru je dôležité zmluvné zabezpečenie zručnosti a kompetencie vývojových pracovníkov subdodávateľa. Prehodnocovanie kompetentnosti dodávateľa možno vykonávať pomocou pravidelných preskúmavaní a kontroly počas návrhu a vývoja. Pri výbere dodávateľa treba postupovať systematicky a uplatniť viaceré ukazovatele ako sú skúsenosť z minulej spolupráce, preskúmanie systému riadenia kvality a ďalších. 173

174 13.21 Informácie o nakupovaní Požiadavka podľa ISO 9001:2000 Informácie o nakupovaní musia opisovať nakupovaný produkt a v prípade potreby aj: a) požiadavky na odsúhlasenie produktu, postupov, procesov a zariadení, b) požiadavky na kvalifikáciu pracovníkov, c) požiadavky na systém riadenia kvality. Organizácia musí oznámením dodávateľovi zaistiť primeranosť špecifikovaných požiadaviek na nákup Návod pre oblasť softvérových produktov Informácie o nakupovaní môžu podľa potreby obsahovať: a) identifikáciu objednaného produktu ( názov, číslo, verzia, konfigurácia), b) požiadavky alebo postup určenia požiadaviek ak neboli určené v čase objednávky, c) normy, ktoré sa majú aplikovať ( napr. komunikačné protokoly, špecifikácia architektúry, normy programovania), d) postupy alebo pracovné inštrukcie poskytnuté dodávateľom e) opis vývojového prostredia ( HW, vývojové nástroje, zariadenia), f) opis cieľového prostredia ( HW a OS), g) požiadavky na pracovníkov ( predpokladaná príprava, vedomosti o produkte). Uvádzané okruhy sa môžu týkať aj subdodávok Verifikácia nakúpeného produktu Požiadavka podľa ISO 9001:2000 Organizácia musí vypracovať a zaviesť kontrolu alebo ďalšie činnosti nevyhnutné na zaistenie, aby nakúpený produkt spĺňal špecifikované požiadavky na nákup. Tam, kde organizácia alebo zákazník chcú vykonať verifikáciu v priestoroch musí v nákupnej informácii určiť zamýšľané verifikačné opatrenia a metódu uvoľnenia produktu Návod pre oblasť softvérových produktov Verifikácia sa môže týkať akceptačného testovania nakúpeného softvéru používaného pri vývoji. 174

175 Väčšina takéhoto softvéru sa nemôže testovať podrobne, pretože je určený na široké použitie a organizácia môže len predpokladať, že je vhodný pre vývoj. Dôležité je overiť jeho podporu v ďalšom období. Ak sa časť vývoja softvéru zabezpečuje subdodávkou alebo sa nakupuje HW a SW, organizácia potrebuje určiť metódu, pomocou ktorej sa zabezpečí verifikácia, validácia a prebratie dodávaných položiek. Ak sa dodávaný softvér integruje do softvéru vytváraného organizáciou môžu byť potrebné ďalšie kroky ako je určenie vývojového prostredia, pravidlá pre testovanie a pod. Môže nastať situácia keď je potrebné do SW vytváraného organizáciou integrovať softvér zo subdodávky vrátane dát, potom organizácia musí produkt a dáta overiť a akceptovať dohodnuté zmluvné podmienky. Pri nákupe alebo získavaní dá treba starostlivo zvážiť formát, nosič, objem, zdroj a obsah dát. Aktuálna môže byť aj doplnková ochrana z dôvodu dôvernosti alebo potreby utajovania dát. Pri nákupe softvéru treba zvážiť formát a médium, na ktorom sa dodávajú. Pri verifikácii zmluvných pracovníkov je možné využívať záznamy o vzdelaní a záznamy o príprave Výroba a poskytovanie služieb v oblasti softvéru Požiadavka podľa ISO 9001:2000 Organizácia musí plánovať, realizovať výrobu a poskytovať služby v riadených podmienkach. Riadené podmienky musia podľa potreby zahŕňať: a) dostupnosť informácií, ktoré opisujú charakteristiky produktu; b) dostupnosť pracovných inštrukcií ak sú potrebné; c) požívanie vhodných zariadení; d) dostupnosť a používanie prístrojov na monitorovanie a meranie; e) zavedenie merania a monitorovania; f) zavedenie činností uvoľňovania, dodávania a činností dodania produktu Návod pre oblasť softvérových produktov Tvorba softvéru a služby Projekt vývoja softvéru sa má organizovať v duchu množiny procesov transformujúcich požiadavky na softvérový produkt. 175

176 Ekvivalentom činností uvádzaných v ISO 9001 sú nasledovné činnosti súvisiace so softvérom: a) uvoľnenie v prípade softvéru ide o zostavenie, vydanie a replikáciu, b) dodávanie - v prípade softvéru ide o dodávku a inštaláciu, c) činnosti po dodaní - v prípade softvéru ide o prevádzku softvéru, údržbu a jeho podporu Zostavenie a vydanie Organizácia musí mať zavedené procesy pre zostavovanie a vydávanie softvéru. Za túto činnosť zodpovedá riadenie konfigurácie. Tvorby softvéru a jeho vydania sa týkajú tieto opatrenia: a) identifikácia softvérových položiek, ktoré sú obsahom každého vydania, b) identifikácia druhov vydania, c) návod umožňujúci pokryť dočasné zmeny alebo opravy Kopírovanie Ak sa to vyžaduje, napr. zmluvou, organizácia musí zabezpečiť kopírovanie softvéru tak, aby prebiehalo správne. Treba pritom zohľadniť toto: a) identifikáciu originálu a kópií vrátane formátu, variantu a verzie, b) druh média pre každú SW položku a označenie, c) dohodu o požadovanej dokumentácii ako sú príručky, návody, licencie a poznámky k vydaniu vrátane identifikácie a balenia d) riadenie prostredia kopírovania, aby sa zaistila opakovateľnosť, e) opatrenia na zaistenie správnosti a úplnosti kópií produktu Dodanie Dodanie sa môže uskutočniť fyzickým prenosom médií obsahujúceho softvér alebo elektronickým prenosom. Dôležitou zložkou je ochrana softvéru počas prenosu Inštalácia Produkt niekedy inštalujú zákazníci alebo tretie strany. V tomto prípade organizácia musí opísať korky, ktoré sa majú vykonať, aby sa produkt nainštaloval. Ak produkt inštaluje organizácia je potrebné zvažovať toto: a) organizácia a podnik majú odsúhlasiť svoje úlohy, zodpovednosť a povinnosti, b) má sa definovať potreba inštalačných inštrukcií, c) má sa definovať potreba konfigurácie softvéru a HW pre konkrétnu inštaláciu, d) má sa definovať potreba zberu dát alebo ich prevodu, e) má sa definovať akceptačný postup po dokončení inštalácie, 176

177 f) má sa zabezpečiť prístup k zariadeniam, g) má sa zabezpečiť dostupnosť kvalifikovaných pracovníkov, h) má sa definovať potreba prípravy súvisiacej so zamýšľaným používaním SW i) má sa definovať potreba zálohovania a obnovy Prevádzka Organizácia vytvárajúca softvér má plánovať a riadiť prevádzku vrátane: a) potreby vytvoriť poradenské centrum helpdesk, b) zabezpečovania potrebnej podpory ako je obnova po havárií, ochrana a zálohovanie dát Udržiavanie Udržiavanie softvéru sa má určiť v zmluve. Organizácia má vytvoriť a zaviesť proces pre udržiavacie činnosti a ich verifikáciu. Udržiavanie môže zahŕňať: a) určenie rozsahu udržiavania, b) identifikáciu východiskového stavu, c) podpornú organizáciu, d) udržiavacie činnosti vrátane riešenia problémov, monitorovania a zisťovania porúch, e) riadenie konfigurácie, testovanie a zabezpečenie kvality, f) návrh harmonogramu vydávania nových verzií, g) pravidlá pre rozširovanie funkčných verzií, h) záznamy. Záznamy o udržiavaní softvéru možno použiť pri hodnotení: a) zlepšovania produktu b) zlepšovania systému riadenia kvality Validácia procesov výroby a poskytovania služieb Požiadavka podľa ISO 9001:2000 Ak výsledný výstup nemožno verifikovať následným monitorovaním alebo meraním, musí organizácia validovať akýkoľvek proces výroby a poskytovania služieb. patria sem procesy, ktorých nedostatky sa objavia až v prevádzke alebo po dodaní služby. Validácia musí prezentovať schopnosť týchto procesov dosahovať plánované prostriedky. 177

178 Organizácia musí pre tieto procesy vypracovať opatrenia zahŕňajúce podľa potreby: a) definované kritériá preskúmania a odsúhlasovania procesov, b) odsúhlasenie zariadení a kvalifikácie pracovníkov, c) používanie špecifických metód a postupov, d) požiadavky na záznamy e) opakovanú validáciu Návod pre oblasť softvérových produktov K príkladom kompenzácie validácie výrobku patrí: pri preskúmavaní návrhu a vývoja zodpovedanie otázky o tom, ako by návrh a vývoj mohol zlyhať sledovanie výskytu zlyhaní pri návrhu a vývoji a možnosti ich vylúčenia Identifikácia a sledovateľnosť Požiadavka podľa ISO 9001:2000 V prípade potreby musí organizácia identifikovať produkt pomocou vhodných prostriedkov počas celej jeho realizácie. Organizácia musí identifikovať stav produktu s ohľadom na požiadavky monitorovania a merania. Tam, kde sa požaduje sledovateľnosť, musí organizácia riadiť a zaznamenávať jednoznačnú identifikáciu produktu. Poznámka: V niektorých priemyselných sektorov sa za prostriedok identifikácie považuje riadenie konfigurácie Návod pre oblasť softvérových produktov Prehľad Identifikácia a sledovateľnosť softvéru sa dosahuje prostredníctvom riadenia konfigurácie. Riadenie konfigurácie je disciplína, ktorá aplikuje technické a administratívne inštrukcie na návrh a vývoj a zabezpečenie konfiguračných položiek vrátane softvéru. Dá sa využívať aj na súvisiacu dokumentáciu a hardvér. Jedným z cieľov riadenia konfigurácie je dokonalé zviditeľnenie konfigurácie produktu a jeho stavu. Ďalším cieľom je aby každý kto pracuje so softvérom používal správne verziu. 178

179 Riadenie konfigurácie Riadenie konfigurácie má zahŕňať: a) jednoznačnú identifikáciu názvu a verzie každej konfiguračnej položky a čau, kedy sa má začleniť do procesu riadenia konfigurácie, b) jednoznačnú identifikáciu každej softvérovej položky, ktoré spoločne vytvárajú konkrétnu verziu celého produktu, c) identifikáciu zostavenia vývojových, dodaných alebo inštalovaných softvérových produktov pre viaceré prostredia, ak je to treba, d) riadenie simultánnych aktualizácií viacnásobných produktov vo viacerých miestach, e) identifikácia, sledovanie a oznamovanie stavu položiek vrátane zmien od začiatku až po uvoľnenie ( vykázanie stavy konfigurácie, f) poskytovanie hodnotenia konfigurácie ( verifikácia a validácia), g) zaistenie riadenia procesu vydávania a dodávky softvéru Sledovateľnosť Sledovanie softvérovej položky alebo produktu má byť zavedené počas celého životného cyklu. Rozsah sledovateľnosti vždy závisí od zmluvy Majetok zákazníka Požiadavka podľa ISO 9001:2000 Organizácia sa musí starať o majetok zákazníka, ktorý má v opatere alebo ktorý používa. Organizácia musí: identifikovať, verifikovať, chrániť, a udržiavať Majetok zákazníka poskytovaný na používanie alebo na zabudovanie do produktu. Ak sa nejaký majetok zákazníka stratí, poškodí alebo sa káže ako nevhodný na používanie, musí sa to oznámiť zákazníkovi a musia sa o tom udržiavať záznamy Návod pre oblasť softvérových produktov Zákazník môže od organizácie žiadať, aby zaobstarala a zabudovala produkt a dáta ním dodané do vytváraného softvéru. 179

180 Môže napríklad ísť o: a) softvérové produkty vrátane produktov dodaných zákazníkom, b) vývojové nástroje, c) vývojové prostredie a služby siete, d) testovacie a prevádzkové dáta, e) rozhrania alebo iné špecifikácie, f) hardvér, g) duševné vlastníctvo, dôverné alebo súkromné informácie. Nesmie sa zabúdať na udržiavanie licencie a podporu pri nasledujúcich revíziách zabudovaného produktu. Majú sa definovať prostriedky, pomocou ktorých sa akceptujú a zabudujú aktualizácie položiek dodaných zákazníkom Ochrana produktu Požiadavka podľa ISO 9001:2000 Organizácia musí zachovávať zhodu produktu počas interného spracúvania a dodávania na zamýšľané použitie. Tento proces zahŕňa identifikáciu, manipuláciu, balenie, skladovanie a ochranu. Ochrana sa môže týkať aj častí produktu Návod pre oblasť softvérových produktov Organizácia produkujúca softvér sa musí ubezpečiť, že jej produkty sa nemenia od okamihu výroby cez kopírovanie, manipuláciu a skladovanie až po okamih dodania. Softvérová informácia nedegraduje v čase, média na ktorých sa nachádza však áno. Pri dodávaní produktu sa majú prijať vodné opatrenia aby sa softvér chránil pred poškodením. Potrebná jej aj antivírusová ochrana. Dodávka môže prebiehať elektronicky alebo fyzicky na dohodnutom médiu. Pri manipulácii, balení, skladovaní a dodávaní softvéru sa majú zvážiť tieto okruhy a opatrenia: a) ukladanie softvérových položiek a udržiavania verzií produktov v zriadených referenčných základniach, b) umožnenie kontrolovaného prístupu a vyvolanie originálu a kópií s ochranou pred neautorizovaným prístupom c) ochrana počítačových médií najmä s ohľadom na vírusy, elektromagnetické a elektrostatické prostredie, 180

181 d) poskytovanie pravidelného zálohovania softvéru e) zabezpečenie včasného skopírovania pre výmenné médiá, f) ukladanie softvérových médií v chránenom prostredí, aby sa zabránilo starnutiu, g) vplyvy využívanej kompresie a dekompresie dát, h) vplyvy využívaných šifrovacích techník Riadenie prístrojov na monitorovanie a meranie Požiadavka podľa ISO 9001:2000 Organizácia musí určiť monitorovanie a meranie, ktoré treba robiť, ako aj prístroje na monitorovanie a meranie, požadované na poskytnutie dôkazu o zhode produktu s určenými požiadavkami. Organizácia musí určiť procesy, ktorými sa dá zaistiť, že meranie a monitorovanie sa dá uskutočniť a že sa vykonáva spôsobom, ktorý je v súlade s požiadavkami na monitorovanie a meranie. Tam, kde sa musí zaistiť platnosť výsledkov merania, zariadenie na meranie sa musí: a) v určených intervaloch alebo pred použitím kalibrovať alebo verifikovať porovnaním s metrologickým etalónmi nadväzujúcimi na medzinárodné a národné etalóny; ak takéto etalóny nejestvujú, musí sa zaznamenať základňa takejto kalibrácie alebo verifikácie. b) podľa potreby opakovane nastaviť alebo opakovane nastaviť, c) identifikovať, aby sa mohol určiť stav jeho kalibrácie, d) ochraňovať pred nastavením, ktoré by mohlo znehodnotiť výsledky, merania, e) chrániť pred poškodením a znehodnotením počas manipulácie, údržby a skladovania. Ak sa zistí, že zariadenie nezodpovedá požiadavkám, organizácia musí okrem iného posúdiť platnosť predchádzajúcich meraní a urobiť záznam. Musia sa udržiavať záznamy o výsledkoch kalibrácie a verifikácie. Ak sa pri monitorovaní alebo meraní používa softvér, musí sa potvrdiť jeho spôsobilosť vyhovovať zamýšľanej aplikácií. Musí sa to vykonať pred prvým použití a podľa potreby sa to musí opakovane potvrdiť Návod pre oblasť softvérových produktov Kalibrácia je technika, ktorá sa používala za neaplikovateľnú na softvér. Môže sa však používať na hardvér a nástroje. Pre splnenie vyššie uvedených požiadaviek sa kalibrácia môže používať na prostredie pre testovanie. 181

182 Monitorovacie a meracie prostriedky používané pri vývoji, testovaní, udržiavaní a prevádzke softvéru zahŕňajú: a) dáta používané pri testovaní softvérového produktu, b) softvérové nástroje (napr. simuláciu, zber údajov, využívanie zdrojov,...), c) počítačový HW d) techniku vytvárajúcu rozhranie s počítačovým HW Všeobecné požiadavky na meranie, analýzu a zlepšovanie Požiadavka podľa ISO 9001:2000 Organizácia musí plánovať a zaviesť monitorovanie, meranie analytické a zlepšovacie procesy potrebné na: a) prezentáciu zhody produktu, b) zaistenie zhody QMS, c) trvalé zlepšovanie efektívnosti QMS. Tieto procesy musia zahŕňať určenie použiteľných metód vrátane štatistických techník a rozsahu ich používania Návod pre oblasť softvérových produktov Účelom procesu merania softvéru je : zbierať, analyzovať, odovzdávať údaje o vyvinutých produktoch a implementovaných procesoch v organizácii, podporovať efektívne riadenie procesov a objektívne demonštrovať kvalitu výrobkov. Procesy monitorovania a merania sa majú chápať ako súčasť plánovania kvality Spokojnosť zákazníka Požiadavka podľa ISO 9001:2000 Organizácia musí ako jedno zmeraní výkonnosti systému riadenia kvality monitorovať informácie týkajúce sa vnímania zákazníkom toho, či splnila jeho požiadavky. Musia sa určiť metódy na získavanie a vyžívanie týchto informácií. 182

183 Návod pre oblasť softvérových produktov Spokojnosť zákazníka v prípade dodávok softvéru zahŕňa najmä: a) analýzu otázok oznámených do poradenského centra týkajúcich sa kvality produktu ako aj výkonnosti služieb, b) metriku kvality u používateľa odvodenú od priamych alebo nepriamych informácií, c) metriky založené na poznatkoch z používania produktu, d) počet softvérových vydaní potrebných na odstránenie problémov po prvej dodávke Interný audit Požiadavka podľa ISO 9001:2000 Organizácia musí v plánovaných intervaloch vykonávať interné audity, aby zistila, či systém riadenia kvality: a) zodpovedá plánovaným opatreniam, požiadavkám certifikačnej normy a požiadavkám určených organizáciou na QMS b) sa efektívne zaviedol a či sa udržuje. Program auditov sa musí plánovať s ohľadom na stav a dôležitosť procesov a auditovaných oblastí, ako aj výsledkov predchádzajúcich auditov. Musia sa určiť kritériá auditu, jeho predmet, frekvencia a metódy auditov. V zdokumentovanom postupe sa musí definovať zodpovednosť za plánovanie a vykonávanie auditov, za oznamovanie výsledkov a Za udržiavanie záznamov ako aj požiadavky na tieto činnosti. Následné činnosti musia zahŕňať verifikáciu zrealizovaných činností a oznámenie výsledkov verifikácie Návod pre oblasť softvérových produktov Ak softvérové organizácie rozdelia svoju prácu do projektov, plánovanie auditov má definovať výber projektov, ktoré budú auditované a majú tak posúdiť zhodu svojich plánov kvality s QMS organizácie, ako aj zhodu projektu s plánom kvality projektu. Výber projektov do plánu auditov by mal pokryť všetky etapy a procesy. Takýto postup môže vyžadovať auditovanie rozličných projektov v rozličných etapách životného cyklu vývoja produktu. 183

184 13.32 Monitorovanie a meranie procesov Požiadavka podľa ISO 9001:2000 Organizácia musí používať vhodné metódy práce na monitorovanie a ak treba na meranie procesov QMS. Tieto metódy musia preukázať schopnosť procesov dosahovať plánované výsledky. Keď sa plánované výsledky nedosiahnu, musí sa podľa potreby urobiť náprava a nápravná činnosť na zaistenie zhody produktu Návod pre oblasť softvérových produktov Organizácie zvyčajne merajú vlastnosti niektorých procesov, aby ich mohli monitorovať, riadiť a hodnotiť. Meranie najčastejšie zahŕňa: a) plánované a skutočné trvanie činnosti v rámci procesu, b) plánované a skutočné náklady na činnosť procesu, c) plánované úrovne kvality a progresívne ukazovatele vybraných charakteristík kvality. Z hľadiska organizácie vyvíjajúcej softvér pôjde o činnosti vykonávané v rámci etáp realizácie projektu zameraného na vývoj softvéru a/alebo vytvorenie celého IS Riadenie nezhodného produktu Požiadavka podľa ISO 9001:2000 Organizácia musí zabezpečiť, aby produkt ktorý nezodpovedá definovaným požiadavkám identifikovala a riadila, aby sa zabránilo jeho neželateľnému použitiu alebo dodaniu. V zdokumentovanom postupe sa musí definovať riadenie a príslušná zodpovednosť a právomoci pri narábaní s nezhodným produktom. Pri nezhodnom produkte organizácia musí postupovať jedným z nasledovných postupov: a) vykoná činnosť, ktorá odstráni nezhodu, b) autorizuje používanie produktu, uvoľnenie alebo prijatie produktu na základe povolenia výnimky pracovníkom s príslušnou právomocou a podľa potrieb zákazníka, c) vykonáva činnosť, ktorá zabráni jeho pôvodnému zamýšľanému použitiu alebo zamýšľanej aplikácií. 184

185 Musia sa udržiavať záznamy o charaktere nezhôd a následne prijatých opatreniach. Ak sa nezhodný produkt opraví musí sa podrobiť opakovanej verifikácii, aby sa preukázala zhoda s požiadavkami. Ak sa nezhodný produkt zistí po dodaní alebo začatí používania, organizácia musí prijať opatrenia primerané účinku alebo potenciálnemu účinku produktu Návod pre oblasť softvérových produktov Pri vývoji softvéru sa segregácia nezhodných položiek môže vykonať ich presunom z produkčného prostredia alebo testovacieho prostredia do oddeleného prostredia. V prípade zabudovaného softvéru môže byť potrebné segregovať nezhodnú položku hardvér, ktorá obsahuje nezhodný softvér. Uvedené činnosti musia prebiehať v rámci riadenia konfigurácie. Pri odstraňovaní nezhôd treba venovať pozornosť najmä týmto skutočnostiam: a) odhalené problémy a ich možné vplyvy na ďalšie časti softvéru sa majú zaznamenať a oznámiť zodpovedným pracovníkom,a by sa sledovali pokiaľ sa nevyriešia, b) majú sa identifikovať a opätovne testovať oblasti, na ktoré majú akékoľvek modifikácie softvéru vplyv, c) má sa určiť priorita nezhôd. Opravou alebo prepracovaním softvéru s cieľom splniť požiadavky vzniká nová verzia. Odstránenie nezhodného produktu sa vo vývoji softvéru dosiahne: a) opravou alebo prepracovaním b) akceptáciou bez opravy alebo po oprave, c) používaní ako nezhodného produktu po zmene požiadaviek, d) odmietnutím Analýza údajov Požiadavka podľa ISO 9001:2000 Organizácia musí určiť, zhromažďovať a analyzovať príslušné údaje, aby prezentovala vhodnosť a efektívnosť QMS a posúdila, kde možno realizovať trvalé zlepšenia efektívnosti systému riadenia kvality. Patria sem údaje z monitorovania a merania a z ďalších príslušných zdrojov. 185

186 Analýza údajov musí poskytovať informácie o: a) spokojnosti zákazníka, b) zhode s požiadavkami na produkt, c) charakteristikách a trendoch procesov a produktov vrátane príležitostí na preventívnu činnosť, d) dodávateľoch Návod pre oblasť softvérových produktov Analýza údajov v organizácii zameranej na tvorbu softvéru môže znamenať analyzovanie správ o problémoch z rozličných úrovní testovania a položky uvádzané v preskúmaniach a rekapituláciách Trvalé zlepšovanie Požiadavka podľa ISO 9001:2000 Organizácia musí trvalo zlepšovať efektívnosť QMS prostredníctvom využívania politiky kvality, cieľov kvality, výsledkov auditu, analýzy údajov, nápravných a preventívnych opatrení a preskúmavaním systému manažmentom Návod pre oblasť softvérových produktov Zlepšovanie možno aplikovať na akýkoľvek proces alebo všetky procesy životného cyklu softvéru. Zahŕňa vytvorenie procesu, posúdenie procesu a zlepšovanie procesu Nápravná činnosť Požiadavka podľa ISO 9001:2000 Organizácia musí vykonávať nápravnú činnosť, aby odstránila príčinu nezhôd a zabránila jej opakovanému výskytu. Musí sa zaviesť dokumentovaný postup, ktorý definuje požiadavky na: a) preskúmanie nezhôd, b) určenie príčin nezhôd, c) vyhodnotenie potreby činnosti na zabránenie vzniku nezhody, d) určenie a zavedenie nevyhnutnej činnosti, e) záznamy výsledkov vykonanej činnosti, f) preskúmanie vykonanej nápravnej činnosti. 186

187 Návod pre oblasť softvérových produktov Ak nápravná činnosť priamo ovplyvňuje softvérové položky, možno na riadenie zmien využívať riadenie konfigurácie. Manažment má preskúmať nápravné činnosti obsahujúce zmeny procesov životného cyklu softvéru Preventívna činnosť Požiadavka podľa ISO 9001:2000 Organizácia musí určiť preventívnu činnosť na odstránenie príčin potenciálnych nezhôd, aby zabránila ich výskytu. Preventívne činnosti musia zodpovedať závažnosti potenciálnych nezhôd. Musí sa vypracovať zdokumentovaný prístup, v ktorom sa definujú požiadavky na: a) určenie potenciálnych nezhôd a ich príčin, b) vyhodnotenie potreby činnosti na zabránenie vzniku nezhôd, c) určenie a zavedenie potrebnej činnosti, d) záznamy výsledkov vykonanej činnosti, e) preskúmanie vykonanej preventívnej činnosti Návod pre oblasť softvérových produktov V prípade organizácie zameranej na tvorbu softvéru môže ísť o potenciálne nezhody týkajúce sa etáp životného cyklu softvéru a nezhody softvérového produktu súvisiace s určitými okolnosťami budúceho používania. 187

188 14 Informačná bezpečnosť Pre pochopenie významu slovného spojenia informačná bezpečnosť existuje v literatúre rôznorodý výklad, avšak s určitými spoločnými znakmi. Príklady: Podľa skrípt Manažment bezpečnosti IT : Informačná bezpečnosť je bezpečnosť informácií a všetkých ostatných aktív informačných technológií a informačných systémov. Podľa ISO/IEC 17799: 2005: Informačná bezpečnosť je uchovanie: a) dôvernosti: zabezpečuje, že informácie sú dostupné len tým, ktorí sú autorizovaní pre prístup k nim; b) integrity: zaisťuje presnosť a úplnosť informácií a metód spracovania; c) dostupnosti: zabezpečuje, aby autorizovaní používatelia mali prístup k informáciám a súvisiacim aktívam vtedy, keď to potrebujú. Informačná bezpečnosť sa dosahuje implementáciou vhodnej sady opatrení, ktorými môžu byť politiky, praktiky, procedúry, organizačné štruktúry a softvérové funkcie. Tieto opatrenia je nutné zaviesť, aby sa zabezpečilo splnenie špecifických bezpečnostných zámerov organizácie. Systém riadenia informačnej bezpečnosti - ISMS (Information Security Management System) je časť celkového systému riadenia, založený na prístupe k riziku podniku, ktorého úlohou je zaviesť, implementovať, prevádzkovať, monitorovať, revidovať, udržiavať a zlepšovať informačnú bezpečnosť 188

189 14.1 Bezpečnostné prvky Táto časť skrípt opisuje prvky zapojené do procesu manažmentu bezpečnosti informácií, a teda aj bezpečnosti informačných systémov Aktíva Správne riadenie aktív je pre úspech spoločnosti životne dôležité a je hlavnou oblasťou, za ktorú zodpovedajú všetky stupne riadenia. Aktíva spoločnosti zahŕňajú: fyzické aktíva (napr. počítačový hardvér, komunikačné prostriedky, budovy); informácie/dáta (napr. dokumenty, databázy); softvér; schopnosť vytvárať určité produkty alebo poskytovať služby; ľudí; nehmotné hodnoty (napr. abstraktné hodnoty spoločnosti, ako sú imidž a dobré meno či povesť). Väčšina alebo všetky z týchto aktív, môžu byť považované za dostatočne cenné na to, aby si zaslúžili určitý stupeň ochrany. Ak nie sú aktíva chránené, je nutné vykonať aspoň odhad rizík, ktoré sú týmto akceptované. Z hľadiska bezpečnosti nie je možné implementovať a udržovať úspešný bezpečnostný program, ak nie sú identifikované aktíva spoločnosti. V mnohých situáciách môže byť proces identifikácie aktív a určenia ich hodnoty vykonaný na vysokej úrovni, teda nie príliš podrobne a nemusí vyžadovať nákladnú, podrobnú a časovo náročnú analýzu. Potrebný stupeň podrobnosti pre túto analýzu by mal byť odvodený od pomeru času a nákladov súvisiacich s analýzou, voči hodnote aktív IT používaných spoločnosťou. V každom prípade by mal byť stupeň podrobnosti analýzy aktív určený na základe bezpečnostných cieľov spoločnosti. V rade prípadov je užitočné združiť aktíva do určitých skupín aktív, ktoré majú svoje špecifické charakteristiky alebo vlastnosti. Atribúty aktív, ktoré by sa mali vziať do úvahy, zahrňujú ich hodnotu alebo citlivosť a akékoľvek inherentné ochranné opatrenia. Požiadavky na ochranu aktív sú ovplyvňované ich zraniteľnosťou pri výskyte špecifických hrozieb. Ak sú tieto aspekty pre vlastníka aktív známe, mali by byť podchytené na tejto úrovni. Prostredie a kultúra, v ktorých spoločnosť vykonáva svoju činnosť, môžu ovplyvniť aktíva a ich atribúty. Napríklad niektoré kultúry považujú ochranu osobných informácií za 189

190 veľmi dôležitú, zatiaľ čo iné prisudzujú tomuto problému menší význam. Variácie prostredia a kultúr môžu mať význam pre medzinárodné organizácie a pre ich používanie systému IT bez ohľadu na medzinárodné hranice Hrozby Aktíva sú predmetom pôsobenia mnohých typov hrozieb. Hrozba má potenciálnu schopnosť spôsobiť nežiaduci incident, ktorý môže mať za následok poškodenie systému alebo spoločnosti a jej aktív. Táto škoda sa môže vyskytnúť ako dôsledok priameho alebo nepriameho útoku na informácie, s ktorými pracuje systém alebo služba IT, napr. ich neautorizované zničenie, sprístupnenie, modifikáciu, deformáciu a nedostupnosť alebo stratu. Aby hrozba spôsobila poškodenie aktív, využíva existujúcu zraniteľnosť aktív, ktorá je daná existujúcimi zraniteľnými miestami. Hrozby môžu mať prírodný alebo ľudský pôvod a môžu byť náhodné alebo úmyselné. Tak náhodné, ako aj úmyselné hrozby by mali byť identifikované a mala by byť odhadnutá ich potenciálna úroveň a pravdepodobnosť ich výskytu. Príklady možných hrozieb podľa ISO/IEC TR sú uvedené v nasledujúcej tabuľke: Ľudské hrozby Hrozby prostredia Úmyselné Odpočúvanie Zmena informácie Hacking systému Nepriateľský program Krádež Náhodné Chyby a zabudnutie Vymazanie súboru Nesprávne smerovanie Fyzické nehody Zemetrasenie Blesk Povodeň Požiar Spoločnosť, riešiaca základné otázky riadenia bezpečnosti IT by si mala vopred získať dostupné štatistické údaje týkajúce sa výskytu rôznych typov hrozieb okolitého prostredia a použiť ich v rámci procesu odhadov hrozieb. Hrozby môžu ovplyvniť špecifické časti spoločnosti, napríklad narušenie osobných počítačov. Niektoré hrozby môžu byť obecné vzhľadom k okolitému prostrediu určitého miesta, v ktorom systém alebo spoločnosť pôsobí, napr. poškodenie budov víchricou alebo bleskom. Hrozba môže vzniknúť vo vnútri spoločnosti, napr. sabotáž zamestnanca alebo zvonku, napr. zlomyseľný prienik hackera alebo priemyselná špionáž. Škoda spôsobená nežiaducim incidentom môže byť dočasnej povahy alebo môže byť trvalá, ako je to v prípade zničenia aktív. Veľkosť škody, spôsobená hrozbou, sa môže pri každom výskyte značne meniť. 190

191 Napríklad: Softvérový vírus môže spôsobiť rôzne veľkú škodu v závislosti na jeho aktivite a zemetrasenie v konkrétnom mieste môže mať rôznu silu pri každom výskyte. Takéto hrozby majú často priradený stupeň sily, ktorá je s nimi spojená. Napríklad: Vírus môže byť napríklad opísaný ako deštruktívny alebo nedeštruktívny a sila zemetrasenia môže byť opísaná v údajoch Richterovej stupnice. Niektoré hrozby môžu pôsobiť na viaceré aktíva. V takom prípade môžu mať za následok rôzne dopady v závislosti na tom, aké aktíva sú ovplyvnené. Účinok softvérového vírusu v jednom osobnom počítači môže mať obmedzený alebo miestny dopad. Ale rovnaký softvérový vírus na sieťovom súborovom serveri môže mať rozsiahly dopad. Rôzne hrozby alebo rovnaká hrozba pri výskyte na inom mieste môžu byť porovnateľné, čo sa týka veľkosti škody nimi spôsobených. Ak je škoda spôsobená hrozbou porovnateľná, potom v praxi je možné uplatniť rovnaký postup pri jej eliminácii. Ak sa však škoda ako následok určitej realizovanej hrozby značne mení, je vhodné uplatniť špecifický prístup pre každý výskyt hrozby. Hrozby majú charakteristiky, ktoré poskytujú o samotnej hrozbe užitočné informácie. Medzi príklady takýchto informácií patria: zdroj (interný alebo externý); motivácia, napr. finančný zisk, konkurenčná výhoda; početnosť výskytu; sila hrozby. Prostredie a kultúry, v ktorých sa subjekty nachádzajú, môžu významne ovplyvniť spôsob, akým spoločnosti s hrozbou zaobchádzajú. V extrémnych prípadoch nemusia byť určité hrozby v určitých kultúrach pokladané za škodlivé. Aspekty prostredia a kultúry však musia byť pri riešení hrozieb zobraté do úvahy. 191

192 Zraniteľnosť Zraniteľnosti, spojené s aktívami, zahrňujú slabé miesta existujúce vo fyzickej, organizačnej, procedurálnej, personálnej, riadiacej, administratívnej, hardvérovej, softvérovej oblasti alebo v oblasti informácií. Môžu byť využité hrozbami, ktoré môžu spôsobiť poškodenie systému IT alebo obchodných cieľov spoločnosti. Zraniteľnosť sama o sebe nie je príčinou škody. Zraniteľnosť je iba podmienkou alebo množinou podmienok, ktoré môžu umožniť hrozbe, aby ovplyvnila aktíva. Je nutné zobrať do úvahy zraniteľnosti vznikajúce z rôznych zdrojov. Napríklad tú, ktorá je aktívam vlastná. Zraniteľnosť môže pretrvávať do doby, pokiaľ sa aktíva samotné zmenia tak, že sa ich zraniteľnosť ďalej nedotýka. Zraniteľnosť zahŕňa slabé miesta v systéme, ktoré môžu byť hrozbou využité a môžu viesť k nežiaducim následkom. To sú príležitosti, ktoré môžu umožniť hrozbe, aby spôsobila škodu. Napríklad : Absencia mechanizmu riadenia prístupu je zraniteľnosť, ktorá by mohla umožniť výskyt hrozby nežiaducim preniknutím k aktívam a ich stratu. Všetky zraniteľné miesta vo vnútri špecifického systému alebo spoločnosti musia byť preskúmané z hľadiska hrozieb, ktoré im hrozia. Okamžitú pozornosť si zaslúžia zraniteľné miesta, u ktorých bola detekovaná určitá konkrétna hrozba. Pretože prostredie, v ktorom spoločnosť pôsobí, sa môže dynamický meniť, mali by byť všetky zraniteľné miesta monitorované, a tak identifikované tie zraniteľné miesta, ktoré začali byť ohrozované starými alebo novými hrozbami. Analýza zraniteľnosti je preskúmavanie slabých miest, ktoré môžu byť využité identifikovanými hrozbami. Táto analýza musí vziať do úvahy prostredie a existujúce ochranné opatrenia. Zraniteľnosť konkrétneho systému alebo aktíva voči určitej hrozbe je vyjadrením ľahkosti, s akou môže byť systém alebo aktívum poškodené. 192

193 Dopad Dopad je dôsledok nežiaduceho incidentu, spôsobeného buď náhodne alebo úmyselne, ktorý má vplyv na aktíva. Následok bezpečnostného incidentu, ktorý vzniká vtedy, keď hrozba využila zraniteľné miesta systému, môžu mať podobu zničenia určitých aktív, poškodenie systému IT a straty dôvernosti, integrity, dostupnosti, individuálnej zodpovednosti, autenticity alebo spoľahlivosti. Možné nepríjemné následky bezpečnostných incidentov zahrňujú taktiež finančné straty a stratu podielu na trhu alebo imidž spoločnosti. Meranie dopadov umožňuje vytvorenie rovnováhy medzi následkami nežiaducich incidentov a nákladmi na ochranné opatrenia slúžiace na ochranu pred nežiaducimi incidentmi. Musí sa prihliadnuť aj na početnosť výskytu nežiaduceho incidentu. To je veľmi dôležité. Aj keď je napríklad veľkosť škody spôsobenej každým výskytom nízka, môže byť súhrnný účinok mnohých incidentov v priebehu určitého času škodlivý. Odhad dopadov bezpečnostných incidentov je dôležitým prvkom pri odhade rizík a výbere ochranných opatrení. Kvalitatívne alebo kvantitatívne meranie dopadu možno dosiahnuť niekoľkými spôsobmi, napr.: určením finančných nákladov; priradením empirickej stupnice sily, napr. 1 až 10; použitím adjektív vybraných z vopred definovaného zoznamu, napr. nízky, stredný, vysoký. 193

194 Riziko Riziko vyjadruje potenciálnu možnosť, že daná hrozba využije zraniteľnosť systému alebo spoločnosti, aby spôsobila stratu alebo poškodenie aktív alebo skupiny aktív, a teda priamo alebo nepriamo spoločnosti. Jednotlivé alebo viacnásobné hrozby môžu využiť jednotlivé alebo viaceré zraniteľné miesta. Rizikový scenár opisuje, ako môže konkrétna hrozba alebo skupina hrozieb využiť konkrétnu zraniteľnosť alebo skupinu zraniteľnosti, ktorým sú vystavené aktíva s možnosťou poškodenia. Riziko je charakterizované kombináciou dvoch faktorov, a to pravdepodobnosťou výskytu nežiaduceho incidentu a jeho dopadom. Akákoľvek zmena aktív, hrozieb, zraniteľností a ochranných opatrení môže významne ovplyvniť riziká. Včasná detekcia alebo poznanie zmien v prostredí alebo v systéme zvyšuje príležitosť realizovať vhodné akcie pre zníženie rizika Zvyškové riziko Riziká sú obvykle použitím ochranných opatrení iba čiastočne zmiernené. Čiastočne je zmiernené všetko, čo je obvykle možno zmierniť. Platí, že čím väčšie zmiernenie následkov bezpečnostného incidentu sa má dosiahnuť, tým vyššie sú s tým spojené náklady. Z toho vyplýva, že v praxi obvykle existujú zvyškové riziká, nakoľko realizované ochranné opatrenia sú ohraničené finančnými prostriedkami, ktoré spoločnosť vynaložila (teda bola ochotná vynaložiť) na riešenie bezpečnostných problémov. Súčasťou posúdenia či existujúca bezpečnosť IT zodpovedá potrebám spoločnosti, je akceptácia zvyškových rizík. Tento proces sa nazýva akceptácia rizík. Vedenie spoločnosti by malo byť upovedomené o všetkých zvyškových rizikách z hľadiska dopadu a pravdepodobnosti výskytu udalosti. Rozhodnutie o akceptácii zvyškových rizík musia vykonať tí, ktorí sú oprávnení akceptovať dopad výskytu nežiaducich incidentov a môžu schváliť implementáciu doplnkových ochranných opatrení v prípade, že zvyškové riziká nie sú pre vedenie spoločnosti akceptovateľné. 194

195 Bezpečnostné opatrenia Bezpečnostné opatrenia, či inak v praxi často nazývané ochranné opatrenia, sú praktiky, postupy alebo mechanizmy, ktoré môžu poskytnúť ochranu pred hrozbou, znížiť zraniteľnosť, obmedziť dopad nežiaduceho incidentu, detegovať nežiaduce incidenty a uľahčiť obnovu. Účinná bezpečnosť konkrétneho prvku, či časti systému alebo spoločnosti, obvykle vyžaduje kombináciu rôznych ochranných opatrení, aby aktívam poskytla primeraný stupeň bezpečnosti. Napríklad mechanizmus riadenia prístupu aplikovaný na počítače, by mal byť podporovaný auditnými kontrolami, personálnymi procedúrami, školením a fyzickou bezpečnosťou. Niektoré ochranné opatrenia môžu existovať už ako súčasť prostredia alebo ako inherentný aspekt aktív, môžu byť v systéme alebo spoločnosti už platné. Ochranné opatrenia môžu vykonávať jednu alebo viac nasledujúcich funkcií: detekciu, odstrašovanie, prevencia, obmedzenie, korekcia, obnova, monitorovanie, povedomie o probléme. Pre konkrétne implementovaný bezpečnostný program je podstatný vhodný výber ochranných opatrení. Mnoho ochranných opatrení môže plniť viacnásobné funkcie. Často je z pohľadu nákladov efektívnejšie vybrať ochranné opatrenia, ktoré spĺňajú viacnásobné funkcie. Príklady oblastí, kde môžu byť použité ochranné opatrenia, zahrňujú: fyzické prostredie, technické prostredie (hardvér, softvér a komunikácie), personál, administratíva, ale aj projektovanie systémov, vývoj softvéru, prevádzka IS, údržba a pod. Povedomie o bezpečnosti je taktiež ochranné opatrenie a vzťahuje sa k personálnej oblasti. Prostredie a kultúra, v ktorých spoločnosti vykonávajú svoju činnosť, môžu mať vplyv na vybrané opatrenia a na povedomie o bezpečnosti v danej spoločnosti. 195

196 Určité ochranné opatrenia vysielajú dôrazný a jasný signál o k bezpečnosti. postoji spoločnosti V tomto smere je dôležité vybrať ochranné opatrenia, ktoré nie sú vo vzťahu ku kultúre alebo štátu, v ktorých spoločnosť vyvíja svoju činnosť, pohoršujúce. Príkladmi bezpečnostných/ochranných opatrení sú: sieťové firewally. monitorovanie a analýza siete. šifrovanie dát k zaisteniu dôvernosti. digitálne podpisy. antivírusový softvér. záložné kópie informácií, rezervné zdroje energie, mechanizmy riadenia prístupu a pod. 196

197 Obmedzenia Obmedzenia pre riešenie bezpečnosti sú obvykle určené vedením spoločnosti a časť z nich vyplýva z prostredia, v ktorom spoločnosť vyvíja svoju činnosť. Príklady niektorých obmedzení, ktoré by mali byť braté do úvahy pri riešení bezpečnosti IT sú nasledovné: organizačné, finančné, zníženia závislosti od prostredia, personálne, časové, právne, technické, kultúrno-sociálne. Všetky tieto faktory musia byť pri výbere a implementácii ochranných opatrení zohľadnené. Periodicky musí byť vykonaná revízia existujúcich a nových obmedzení a musia byť identifikované akékoľvek zmeny. Malo by byť rovnako zaznamenané, že obmedzenie sa môže meniť s časom, s geografickým a sociálnym vývojom, rovnako ako s pracovnou kultúrou spoločnosti. Prostredie a kultúra, v ktorých spoločnosť vyvíja svoju činnosť, môžu mať vplyv na niekoľko bezpečnostných prvkov, zvlášť na hrozby, riziká a ochranné opatrenia. 197

198 Vzťahy medzi bezpečnostnými prvkami Základné vzťahy medzi bezpečnostnými prvkami podľa ISO/IEC TR sú vyjadrené Obrázkom č Obrázok č Základné vzťahy medzi bezpečnostnými prvkami Z obrázku č okrem iného napr. vyplýva, že: ochranné opatrenia chránia aktíva spoločnosti pred hrozbami využívajúcimi zraniteľné miesta aktív; zraniteľné miesta zvyšujú potenciálne bezpečnostné riziká spoločnosti a indikujú požiadavky na ochranu, ktoré sú splnené implementáciou bezpečnostných opatrení; hrozby zvyšujú bezpečnostné riziká, ktoré vyvolávajú potrebu implementácie bezpečnostných opatrení. 198

199 15 Analýza a manažment rizík 15.1 Analýza rizík Analýza rizík je proces, prostredníctvom ktorého sa identifikujú bezpečnostné riziká, ktoré je potrebné kontrolovať alebo akceptovať. V kontexte bezpečnosti IS analýza rizík IS zahŕňa analýzu hodnôt aktív, hrozieb a zraniteľností a určenie potenciálnych rizík. Riziká sú určené z hľadiska možného dopadu spôsobeného narušením dôvernosti, integrity, dostupnosti, individuálnej zodpovednosti, autenticity alebo spoľahlivosti. Výsledkom analýzy rizík je poznatok o pravdepodobných rizikách týkajúcich sa aktív spoločnosti. Analýza rizík je východiskom pre manažment rizík a môže byť vykonaná bez zbytočných časových investícií a investícií do zdrojov, uskutočnením počiatočnej krátkej analýzy všetkých systémov. Takáto analýza určí, ktoré systémy môžu byť adekvátne chránené pomocou vzorovej sústavy prijatých praktických postupov a základných kontrol a pre ktoré systémy bude potrebné vykonať podrobnú analýzu rizík Prístupy k analýze rizík Podľa ISO/IEC TR 13335, pred začatím akýchkoľvek aktivít súvisiacich s analýzou rizík, by spoločnosť mala mať k dispozícii stratégiu pre túto analýzu. Jej podstatné zložky (metódy, techniky, atď.) by mali byť dokumentované v politike bezpečnosti IT spoločnosti. Prostriedky a kritériá pre výber metódy analýzy rizík by mali byť odsúhlasené. Stratégia analýzy rizík by mala zaistiť, že vybraný prístup k analýze rizík je vhodný pre dané prostredie, a že zameriava bezpečnostné úsilie tam, kde je to skutočne potrebné. Ďalej opísané alternatívy charakterizujú štyri rôzne prístupy k analýze rizík. Základným rozdielom medzi nimi je uplatňovaná hĺbka analýzy rizík. Keďže je zväčša príliš nákladné vykonávať detailnú analýzu rizík pre všetky systémy prevádzkované spoločnosťou a súčasne nie je vhodné venovať len malú pozornosť vážnym rizikám, je potrebné dosiahnuť rovnováhu medzi týmito alternatívami. 199

200 Okrem možnosti nerobiť nič, t. j. prijať fakt, že aktíva sú vystavené neurčitému množstvu rizík neznámej veľkosti a závažnosti, existujú štyri základné možnosti pre analýzu rizík IT spoločnosti: použiť rovnaký základný prístup pre riešenie bezpečnosti všetkých systémy IT, bez ohľadu na riziká hroziace systémom a akceptovať, že zaisťovaná úroveň bezpečnosti nemusí byť vždy primeraná; použiť pre vykonanie analýzy rizík neformálny prístup a sústrediť sa na tie systémy IT, ktoré sú vnímané ako systémy vystavené vysokým rizikám; vykonať detailnú analýzu rizík s využitím formálneho prístupu pre všetky systémy; vykonať počiatočnú analýzu rizík na vysokej úrovni s cieľom identifikovať systémy IT vystavené vysokým rizikám a tie, ktoré sú pre podnikateľské aktivity kritické a následne realizovať detailnú analýzu rizík týchto systémov a súčasne aplikovať základnú bezpečnosť pre všetky ostatné systémy. Ak sa spoločnosť rozhodne nerobiť s bezpečnosťou nič alebo odloží implementáciu bezpečnostných opatrení, manažment by si mal byť vedomý možných následkov tohto rozhodnutia. Hoci takéto riešenie problému riadenia bezpečnosti IT nevyžaduje žiaden čas, peniaze, personál ani iné zdroje, má množstvo nevýhod. Ak si spoločnosť je istá nekritickou povahou svojich systémov, môže zotrvávať na pozícii nesystémovo nechránenej spoločnosti voči vážnym následkom. Súčasne však platí, že spoločnosť nekoná v súlade s legislatívou, jej reputácia môže utrpieť následkom narušenia bezpečnosti a môže sa ukázať, že zo strany spoločnosti neboli vykonané potrebné preventívne kroky. Ak sa bezpečnosť IT týka spoločnosti len veľmi málo alebo ak spoločnosť nemá žiadne podnikateľsky kritické systémy, potom môže byť táto stratégia vhodná (dočasne akceptovateľná). Takáto spoločnosť je však v pozícii, že nepozná, aká dobrá alebo zlá je jej bezpečnostná situácia v skutočnosti, čo pravdepodobne nie je dobré riešenie pre väčšinu spoločností. Poznámka: Štatutárni zástupcovia spoločnosti by takéto rozhodnutia mali mať schválené rozhodnutiami vlastníkov, napr. uznesením valného zhromaždenia. 200

201 Základný prístup Pri tejto alternatíve by spoločnosť mala aplikovať základnú bezpečnosť pre všetky systémy IT, výberom štandardných bezpečnostných opatrení. Škála štandardných bezpečnostných opatrení je navrhnutá v základných dokumentoch a praktických kódexoch vydaných jednotlivými štátmi. Tento prístup má niekoľko výhod, ako napríklad: pre implementáciu každého bezpečnostného opatrenia je na analýzu rizík a manažment rizík potrebné len minimálne množstvo zdrojov, preto sa na výber bezpečnostných opatrení vynaloží menej času a úsilia; ak veľké množstvo systémov používaných v spoločnosti funguje v podobnom prostredí a ak ich bezpečnostné potreby sú porovnateľné, základné opatrenia môžu ponúknuť nákladovo-efektívne riešenie, pretože tie isté alebo podobné opatrenia môžu byť bez veľkého úsilia zavedené v mnohých systémoch. Nevýhody tejto alternatívy sú: ak je základná úroveň stanovená privysoko, v niektorých systémoch IT môže byť úroveň bezpečnosti nadmerná; ak je úroveň stanovená prinízko, v niektorých systémoch IT môže byť nedostatočná úroveň bezpečnosti, čo má za následok vyšší stupeň vystavenia rizikám; môžu byť ťažkosti s riadením bezpečnostne - relevantných zmien. Napríklad, ak je systém aktualizovaný, môže byť zložité zhodnotiť, či sú pôvodné základné bezpečnostné opatrenia ešte stále dostatočné. Ak majú všetky systémy IT používané v spoločnosti nízke bezpečnostné požiadavky, potom tento prístup môže byť najviac nákladovo-efektívnou stratégiou. V takomto prípade je potrebné určiť základnú úroveň tak, aby odrážala stupeň ochrany potrebný pre väčšinu systémov IT. Väčšina spoločností musí spĺňať určité minimálne štandardy na ochranu citlivých dát a byť v súlade s legislatívou a nariadeniami, napr. s legislatívou na ochranu dát. Tam, kde sa však informačné systémy spoločnosti odlišujú v citlivosti z hľadiska ich väzby k podnikateľskej činnosti spoločnosti, vo veľkosti a zložitosti, by aplikovanie spoločných štandardov na všetky systémy nebolo logické, primerané ani nákladovoefektívne. 201

202 Neformálny prístup Táto možnosť znamená vykonať neformálne pragmatické analýzy rizík. Neformálny prístup nie je založený na štruktúrovaných metódach, ale využíva vedomosti a skúsenosti jednotlivcov. Výhodou tejto alternatívy je: zvyčajne nevyžaduje mnoho zdrojov ani času. Na vykonanie takejto neformálnej analýzy nie sú potrebné žiadne dodatočné odbornosti a je vykonávaná rýchlejšie než detailná analýza rizík. Existuje však aj niekoľko nevýhod a to: bez určitého druhu formálneho prístupu alebo kompletného kontrolného zoznamu narastá pravdepodobnosť vynechania niektorých dôležitých detailov; zdôvodnenie implementácie bezpečnostných opatrení na základe rizík zhodnotených týmto spôsobom bude problematické; jednotlivci, ktorí majú minimálne skúsenosti s analyzovaním rizík môžu pociťovať nedostatok pomôcok pre splnenie tejto úlohy; niektoré opatrenia realizované v minulosti mohli byť odvodené od zraniteľností, t. j. opatrenia boli implementované na základe identifikovaných zraniteľností, bez zváženia reálnej existencie nejakých hrozieb, ktoré by mohli využiť tieto zraniteľnosti, teda bez ohľadu na existenciu reálnej potreby bezpečnostných opatrení; do procesu analýzy môže byť zavedený určitý stupeň subjektivity; osobné predsudky posudzovateľa môžu ovplyvniť výsledky; môžu vzniknúť problémy ak osoba, ktorá vykonávala neformálnu analýzu rizík, opustí spoločnosť. Z dôvodu vyššie uvedených nevýhod nepredstavuje táto alternatíva pre mnohé spoločnosti efektívny prístup k analýze rizík. 202

203 Detailná analýza Treťou možnosťou je vykonať detailné analýzy rizík pre všetky systémy IT v spoločnosti. Detailná analýza rizík zahŕňa hĺbkovú identifikáciu a ohodnotenie aktív, ohodnotenie hrozieb pre tieto aktíva a ohodnotenie zraniteľností. Výsledky týchto aktivít sa potom použijú na ohodnotenie rizík a následne na identifikovanie opodstatnených bezpečnostných opatrení, implementovaním ktorých sa dosiahne požadovaná úroveň bezpečnosti systémov. Výhody tohto prístupu sú: je pravdepodobné, že budú pre všetky systémy identifikované vhodné opatrenia; výsledky detailných analýz môžu byť použité pri riadení zmien v spôsobe zaisťovania bezpečnosti. Nevýhody tejto alternatívy sú nasledovné: získanie výsledkov vyžaduje značné množstvo času, úsilia a odborných znalostí; je možné, že bezpečnostné potreby niektorého kritického systému budú ošetrené príliš neskoro, lebo všetky systémy IT sa posudzujú rovnako podrobne a na ukončenie analýz je potrebné značné množstvo času. Preto nie je vhodné používať detailnú analýzu rizík pre všetky systémy IT. Ak sa zvolí tento prístup k analýze rizík systémov prevádzkovaných spoločnosťou, existuje niekoľko možných implementácií: použiť štandardný prístup, ktorý spĺňa kritériá zachytené napr. v technickej správe ISO/IEC TR časť 3; použiť štandardný prístup rôznymi spôsobmi, vhodnými pre spoločnosť, napr. použiť metódu modelovania rizík pomocou podporných softvérových nástrojov, napr. nástrojom CRAMM. 203

204 Kombinovaný prístup Štvrtou možnosťou je najprv vykonať počiatočnú analýzu rizík na vysokej úrovni pre všetky systémy IT, koncentrujúc sa na hodnotu daných systémov z hľadiska spoločnosti a na vážne riziká, ktorým sú vystavené. Potom pre tie systémy, ktoré sú identifikované ako dôležité pre podnikanie spoločnosti a/alebo ako systémy vystavené vysokým rizikám, sa následne vykoná detailná analýza rizík, a to v poradí podľa určených priorít. Pre všetky ostatné systémy IT by sa mal zvoliť základný prístup pre riešenie ich ochrany. Táto alternatíva je vlastne kombináciou najlepších prvkov základného prístupu a detailnej analýzy rizík. Poskytuje dobré vyváženie medzi minimalizáciou času a úsilia vynaložených na identifikovanie bezpečnostných opatrení, pri súčasnom zabezpečení adekvátnej ochrany pre vysoko rizikové systémy. Ďalšími výhodami tejto alternatívy sú: použitie počiatočného rýchleho a jednoduchého prístupu. Pravdepodobne pomôže získať podporu vedenia spoločnosti pre schválenie programu realizácie komplexu analýz rizík; malo by byť možné rýchlo si vytvoriť strategickú predstavu o bezpečnostnom programe spoločnosti. Tento prístup je dobrou pomôckou pri plánovaní; zdroje a peniaze môžu byť uplatnené tam, kde sú najužitočnejšie. Systémy, ktoré pravdepodobne potrebujú najvyššiu ochranu, budú ošetrované prvé a následné činnosti v rámci pokračujúceho riešenia budú úspešnejšie. Jedinou potenciálnou nevýhodou je: že počiatočné analýzy rizík vykonané na vysokej úrovni sú potenciálne menej presné, a preto niektoré systémy nemusia byť správne identifikované ako systémy vyžadujúce detailnú analýzu rizík. Tieto systémy však budú stále pokryté základnými opatreniami pre bezpečnosť, taktiež môžu byť v prípade potreby kedykoľvek opätovne posúdené s cieľom zistiť, či nie je potrebné aplikovať detailný prístup k analýze ich rizík. Uplatnenie analýzy rizík na vysokej úrovni kombinovanej so základným prístupom k riešeniu otázok bezpečnosti všetkých systémov a tam, kde je to potrebné a následné uplatnenie detailnej analýzy rizík poskytuje väčšine spoločností najefektívnejšiu cestu k správnemu riadeniu bezpečnosti IT. Každý vyššie spomínaný prístup k analýze rizík poskytuje určité množstvo odporúčaní na zníženie bezpečnostných rizík riešeného systému na prijateľnú úroveň. 204

205 Tieto odporúčania by mali byť schválené vedením spoločnosti. Vedenie spoločnosti by malo súčasne schváliť: kritériá pre určovanie prijateľných úrovní rizík pre posudzovaný systém; kritériá pre výber bezpečnostných opatrení, ktorými sa budú znižovať poznané bezpečnostné riziká na prijateľnú úroveň; pravidlá pre akceptáciu zvyškových rizík zostávajúcich po implementácii všetkých schválených ochranných opatrení. Nutným podkladom pre takúto činnosť vedenia spoločnosti sú poznatky o výhodách týkajúcich sa implementácie jednotlivých druhov ochranných opatrení a o znížení rizík dosiahnutom týmito opatreniami. 205

206 15.2 Manažment rizík Manažment rizík zahŕňa štyri rôzne činnosti: určenie celkovej stratégie analýzy a manažmentu rizík vhodnej pre spoločnosť, v rámci kontextu bezpečnostnej politiky IT spoločnosti; výber bezpečnostných opatrení pre jednotlivé systémy IT, ako reakcia na výsledky analýzy rizík; formulovanie bezpečnostných politík IS a v prípade potreby aktualizovanie globálnej politiky bezpečnosti IT spoločnosti (kde je to potrebné aj politík bezpečnosti IT organizačných útvarov spoločnosti); vytvorenie bezpečnostných projektov systémov a plánov bezpečnosti IS pre implementovanie bezpečnostných opatrení, založených na schválených politikách bezpečnosti systémov. Plány bezpečnosti IS budú pritom súčasťou schvaľovaného obchodného plánu spoločnosti. Všeobecne platí, že manažment rizík systému je najefektívnejší, ak prebieha v rámci celého životného cyklu systému. Zatiaľ čo pri novo budovaných systémoch môže byť uplatnený ucelený cyklus manažmentu rizík, v prípade pôvodných systémov, t. j. skôr vybudovaných systémoch, môže byť podľa potreby proces manažmentu rizík iniciovaný v ktoromkoľvek bode životného cyklu systému. Súčasne platí, že proces manažmentu rizík je sám osebe cyklickým procesom. Stratégia analýzy rizík, schválená spoločnosťou môže určovať, či revízia výsledkov manažmentu rizík bude vykonaná v určitých bodoch životného cyklu systému alebo v určitej frekvencii vždy po uplynutí vopred definovanej doby. V praxi môžu existovať aj prípady spustenia procesu manažmentu rizík nadväzujúce na predchádzajúce revízie, s cieľom kontrolovať pokrok v implementácii schválených ochranných opatrení pre daný systém. Taktiež môže existovať aj požiadavka vykonávať manažment rizík v priebehu návrhu a vývoja systému, čím sa zaistí, že bezpečnosť je navrhnutá a implementovaná v najvýhodnejšej fáze z hľadiska nákladov. Ak sú v prevádzkovanom systéme plánované významné zmeny, mal by byť taktiež iniciovaný proces opakovaného manažmentu rizík. Pri použití akejkoľvek metódy alebo techniky manažmentu rizík je dôležité zaistiť rovnováhu medzi minimalizáciou času a zdrojov vynaložených pri identifikácii a implementácii ochranných opatrení a súčasnom zaistení reálnej ochrany všetkých systémov prevádzkovaných spoločnosťou odpovedajúcim spôsobom. 206

207 Manažment rizík IS je proces zameraný na porovnanie zistených rizík s výhodami a/alebo nákladmi na ochranné opatrenia, ktoré ich môžu eliminovať. Odvodzuje stratégiu ich implementácie a bezpečnostnú politiku systému od globálnej bezpečnostnej politiky IT a obchodných cieľov spoločnosti. V rámci manažmentu rizík všetkých systémov prevádzkovaných spoločnosťou by sa mali vziať do úvahy rôzne typy ochranných opatrení a mala by byť vykonaná analýza nákladov, ako aj prínosov ich realizácie. Ochranné opatrenia, ktoré budú implementované pre zaistenie požadovanej bezpečnosti daného systému, by mali byť vybrané v relácii k rizikám a potenciálnym dopadom detekovaných bezpečnostných rizík. Musí byť tiež zohľadnená úroveň prijateľného zostatkového rizika. Taktiež je potrebné si uvedomiť, že ochranné opatrenia samé osebe môžu obsahovať zraniteľnosti a vo svojom dôsledku tak zaviesť nové riziká. Preto musí byť venovaná patričná pozornosť výberu vhodných ochranných opatrení nielen z hľadiska zníženia rizík, ale taktiež aj z hľadiska, aby sa ich implementáciou nezaviedli potenciálne nové riziká. Preto kľúčovým prvkom/činnosťou v rámci manažmentu rizík je ohodnotenie rizík a určenie spôsobu ich zníženia na prijateľnú úroveň. Je pritom nevyhnutné vziať do úvahy podnikateľské ciele spoločnosti, rovnako ako aj organizačné aspekty a špecifické potreby a riziká každého systému. Proces manažmentu rizík zahŕňajúci detailnú analýzu rizík je znázornený na obrázku č

208 Obrázok č Proces manažmentu rizík IS 208

209 Výber bezpečnostných opatrení Jedno z možných usmernení z hľadiska výberu bezpečnostných opatrení pre konkrétny IS je štandard ISO/IEC TR 13335, časť 4. Jeho cieľom je poskytnúť usmernenia pre výber bezpečnostných opatrení pre situácie, kde sa prijalo jedno z možných rozhodnutí vybrať bezpečnostné opatrenia pre IS: podľa typu a charakteristiky IS, podľa širokého zhodnotenia bezpečnostných otázok a hrozieb, v súlade s výsledkami podrobnej analýzy rizík Výber bezpečnostných opatrení podľa typu a charakteristiky IS Existujú dva hlavné prístupy k výberu opatrení, t.j. použitie základného prístupu a vykonanie podrobnej analýzy rizík. Základné členenie postupu pri výbere bezpečnostných opatrení v závislosti od typu realizovanej analýzy rizík znázorňuje obrázok č Začiatok procesu analýzy rizík Analýza rizík na vysokej úrovni Podrobná analýza rizík Základný prístup Jednoduchý alebo pokročilejší základný prístup? Výber opatrení podľa typu systému IT Výber opatrení podľa typu bezpečnostných záujmov a hrozieb Obrázok č Spôsoby výberu bezpečnostných opatrení 209

210 Základný prístup, ktorý má byť použitý, by mal byť vybraný v závislosti na prostriedkoch, ktoré môžu byť vynaložené na proces výberu, vnímaných bezpečnostných záujmoch a type a charakteristike posudzovaného IS. Ak organizácia (z akéhokoľvek dôvodu) nechce vynaložiť na výber bezpečnostných opatrení veľa času a úsilia, môže byť vhodný základný prístup, navrhujúci opatrenia bez ďalšieho posudzovania. Ak je však prevádzka organizácie stredne závislá na systéme alebo službách IT a/alebo sú držané citlivé informácie, je veľmi pravdepodobné, že budú potrebné dodatočné informácie. V tomto prípade sa veľmi odporúča, aby sa uplatnil aspoň náhľad vysokej úrovne na dôležitosť informácií a pravdepodobné hrozby, kvôli získaniu lepšej predstavy o bezpečnostných opatreniach potrebných na najefektívnejšiu ochranu daného IS. Ak je prevádzka organizácie vysoko závislá na systéme alebo službách IT a/alebo sú držané veľmi citlivé informácie, riziko môže byť vysoké a najlepším spôsobom na identifikovanie primeraných opatrení je podrobná analýza rizík. Základnú ochranu IS možno dosiahnuť identifikovaním a aplikovaním sady relevantných opatrení, ktoré sú vhodné v škále nízko rizikových okolností, teda spĺňajú prinajmenšom minimálne bezpečnostné potreby. Primerané základné bezpečnostné opatrenia možno identifikovať napríklad použitím katalógov, ktoré navrhujú sady opatrení pre typy systémov IT na ich ochranu proti najbežnejším hrozbám. Tieto katalógy bezpečnostných opatrení obsahujú informácie o kategóriách opatrení alebo podrobné opatrenia alebo oboje, ale obvykle neoznačujú, ktoré opatrenia by mali byť aplikované v určitých konkrétnych podmienkach. Je možné, že ak IS organizácie (alebo jej časti) sú veľmi podobnej povahy a poskytujú podobné služby, opatrenia vybrané prostredníctvom základného prístupu môžu byť aplikovateľné na všetky systémy IT. Obrázok č ukazuje rôzne spôsoby použitia základného prístupu pri výbere bezpečnostných opatrení. 210

211 Výber podľa typu IS (najjednoduchší prístup) Pre konkrétny rámec organizácia, odvetvie podnikania, alebo služba, atď. Základný prístup... Katalóg opatrení Výber podľa bezpečnostných záujmov a hrozieb (jemnejší prístup) Opatrenia pre situáciu 1 Opatrenia pre situáciu 2 Opatrenia pre situáciu n Výber podľa podrobných ohodnotení (prístup prispôsobený pre každú situáciu) Príklady: Oddelená pracovná stanica Servery pripojené k internej sieti Procesy v ktorých dôvernosť je záujmom, posudzujúc hrozbu používania softvéru neautorizovanými používateľmi. Obrázok č. č Prístupy k výberu opatrení Proces výberu bezpečnostných opatrení vždy vyžaduje určité vedomosti o type a charakteristike posudzovaného IS (napríklad ide o samostatnú pracovnú stanicu alebo pracovnú stanicu pripojenú k sieti), lebo majú významný vplyv na opatrenia vybrané na ochranu systému. Taktiež je nápomocné mať predstavu o infraštruktúre, v zmysle budov, miestností, atď. Ďalším dôležitým faktorom zúčastneným na výbere opatrení je ohodnotenie existujúcich a/alebo už plánovaných opatrení. Toto zabráni vynakladaniu nepotrebnej práce a strate času, úsilia a peňazí. Pri vyberaní opatrení by mali byť brané do úvahy podnikateľské požiadavky a prístup organizácie k bezpečnosti. 211

212 Nakoniec je dôležité určiť, či tieto ohodnotenia poskytujú dostatok informácií pre výber základných opatrení alebo či je potrebné podrobnejšie ohodnocovanie, resp. podrobná analýza rizík Identifikácia typu systému Pre ohodnotenie existujúceho alebo plánovaného IS by mal byť posudzovaný IS porovnaný s nasledovnými komponentmi a mali by byť identifikované komponenty predstavujúce systém. V odseku č. 9, štandardu ISO/IEC TR 13335, časť 4. sú navrhnuté opatrenia pre každý z ďalej uvedených komponentov. Komponentmi, z ktorých sa vyberá sú: samostatná pracovná stanica, pracovná stanica (klient bez zdieľaných prostriedkov) pripojená k sieti, server alebo pracovná stanica so zdieľanými prostriedkami pripojenými k sieti Identifikácia fyzických/environmentálnych podmienok Ohodnotenie prostredia zahŕňa identifikáciu fyzickej infraštruktúry podporujúcej existujúci a plánovaný IS, ako aj súvisiace existujúce a/alebo plánované bezpečnostné opatrenia. Keďže všetky bezpečnostné opatrenia by mali byť kompatibilné s fyzickým prostredím, tieto ohodnotenia sú kľúčové pre ich úspešný výber. Pri posudzovaní infraštruktúry môžu byť nápomocné nasledovné otázky. Čitateľ by mal myslieť aj na prostredie organizácie a všetky zvláštne okolnosti, ktoré je potrebné vziať do úvahy. Okruh a budova - Kde je budova situovaná - v rámci vlastného pozemku s obvodovým múrom alebo na ulici s rušnou dopravou atď.? - Je osadenstvo budovy z jednej skupiny alebo je rôznorodé? - Ak je rôznorodé, kto sú tí iní obyvatelia? - Kde sú citlivé/kritické oblasti? Riadenie prístupu - Kto má prístup do budovy? - Je v prevádzke systém riadenia fyzického prístupu? - Aká robustná je štruktúra budovy? - Aké robustné sú dvere, okná atď. a aká ochrana je im poskytnutá? - Je budova strážená a ak áno, je to 24 hodín denne, alebo len v pracovnom čase? - Je budova a/alebo miestnosť kde sa nachádza kritické vybavenie IT zabezpečená alarmom pre prípad vniknutia? Ochrana na mieste - Ako je (sú) chránená miestnosť (miestnosti) obsahujúca IS? - Aké zariadenia detekcie, alarmu a potlačenia požiaru sú inštalované a kde? - Aké zariadenia detekcie prenikania a straty vody sú inštalované a kde? - Sú inštalované zariadenia ako UPS, kanalizácia a klimatizácia (na kontrolovanie teploty a vlhkosti)? 212

213 Odpovedaním na tieto otázky možno ľahko identifikovať existujúce fyzické a s nimi súvisiace bezpečnostné opatrenia. Ak nejde o časovo náročný úkon, je výhodné pri posudzovaní umiestnenia budovy v rovnakom čase identifikovať problémy súvisiace s dverami, zámkami, riadením a procedúrami fyzického prístupu Ohodnotenie existujúcich/plánovaných opatrení Po ohodnotení podmienok fyzického prostredia a komponentov systému IT by mali byť identifikované všetky už aplikované alebo naplánované bezpečnostné opatrenia. Toto je potrebné, aby sa predišlo opätovnému výberu už existujúceho alebo plánovaného opatrenia a vedomosti o implementovaných alebo plánovaných opatreniach napomôžu pri výbere ďalších opatrení, ktoré budú fungovať v kombinácii s nimi. Pri výbere opatrení by sa mala posudzovať aj kompatibilita existujúcich opatrení s vybranými. Bezpečnostné opatrenie môže byť v konflikte s iným opatrením, alebo môže brániť jeho úspešnému fungovaniu a poskytovanej ochrane. Pre identifikáciu existujúcich alebo plánovaných opatrení môžu byť nápomocné nasledovné aktivity: prezrieť dokumenty obsahujúce informácie o bezpečnostných opatreniach (napríklad plány alebo koncepcie bezpečnosti IT) - ak je proces bezpečnosti dobre dokumentovaný, mali by tam byť uvedené všetky existujúce alebo plánované opatrenia a stav ich implementácie, preveriť so zodpovednými osobami (napr. bezpečnostný manažér IS, manažér budovy alebo manažér prevádzky) a s používateľmi, ktoré bezpečnostné opatrenia sú pri posudzovanom IS skutočne implementované prejsť budovou sledujúc opatrenia, porovnávať implementované so zoznamom tých, ktoré by mali byť implementované a preveriť implementované, či fungujú správne a efektívne. Môže dôjsť k zisteniu, že existujúce opatrenia presahujú aktuálne potreby. V takom prípade by sa malo zvážiť odstránenie týchto opatrení. Pri zvažovaní odstránenia nadbytočných alebo nepotrebných opatrení, by sa mali vziať do úvahy faktory bezpečnosti a nákladov. Keďže bezpečnostné opatrenia sa vzájomne ovplyvňujú, odstránenie nadbytočných opatrení by mohlo znížiť celkovú bezpečnosť. Okrem toho môže byť lacnejšie nechať opatrenia v prevádzke než ich odstrániť alebo, najmä ak majú opatrenia vysoké náklady na údržbu, môže byť lacnejšie odstrániť ich. Všeobecne platí, že existujú dve rôzne sady opatrení, mechanizmov a/alebo procedúr, ktoré možno aplikovať na ochranu IS. Na jednej strane existuje niekoľko kategórií najmä organizačných opatrení, ktoré sú všeobecne aplikovateľné pre každý systém, ak si ich vynútia špecifické okolnosti, bez ohľadu na jednotlivé komponenty IS. 213

214 Z dôvodu svojej všeobecnej použiteľnosti by mali byť opatrenia z týchto kategórií vždy brané do úvahy. Okrem toho implementácia mnohých z nich nie je nákladná, keďže sú založené na zavedení organizačných štruktúr a procedúr. Všeobecne použiteľnými kategóriami bezpečnostných opatrení pre riešenie bezpečnosti IS sú: Manažment a politika bezpečnosti, Preverovanie dodržiavania bezpečnosti, Ošetrovanie incidentov, Personál, Otázky prevádzky, Plánovanie nepretržitosti (kontinuity) činnosti, Fyzická bezpečnosť. Na druhej strane existujú opatrenia špecifické pre IS - výber týchto opatrení závisí na type a charakteristikách analyzovaného systému IT. Okrem všeobecne použiteľných opatrení, by mali byť pre každý relevantný typ komponentu systému vybrané aj opatrenia špecifické pre daný IS. Nasledovná tabuľka poskytuje príklad, ako začať proces výberu opatrení špecifických pre daný IS. V tomto príklade "X" označuje opatrenia, ktoré by mali byť implementované za normálnych okolností a "(X)" označuje opatrenia, ktoré by mohli byť potrebné za určitých okolností. Samozrejme, vždy je možné, že jedna alebo viac z týchto kategórií alebo špecifických opatrení nebudú pre určitý IS použiteľné. Napríklad šifrovanie nemusí byť potrebné, ak posielané alebo prijímané informácie nevyžadujú zachovanie dôvernosti a integritu je možné overiť inak. Podrobnejší výber môže byť opäť vykonaný len pri zvážení ďalších informácií. 214

215 Typ bezpečnostného opatrenia I&A I&A založená na niečom, čo používateľ pozná I&A založená na niečom, čo používateľ vlastní I&A založená na niečom, čím používateľ je Riadenie a audit logického prístupu Politika riadenia prístupu Oddelené počítače Pracovná stanica (klient bez zdieľaných prostriedkov) pripojená k sieti X X X X X X (X) (X) (X) X Prístup používateľov k počítačom X X X Prístup používateľov k dátam, X X X službám a aplikáciám Revidovanie a aktualizovanie X prístupových práv Auditné záznamy X X X Zlomyseľný kód Skenery X X X Preverovače integrity X X X Riadenie obehu prenosných médií X X X Procedurálne opatrenia X X X Manažment sietí Prevádzkové procedúry X Systémové plánovanie X Konfigurácia sietí X Oddelenie sietí X Monitorovanie sietí X Detekcia narušení X Kryptografia Ochrana dôvernosti dát (X) (X) (X) Ochrana integrity dát (X) (X) (X) Nepopierateľnosť (X) (X) Autentičnosť dát (X) (X) (X) Manažment kľúčov (X) (X) (X) Server alebo pracovná stanica so zdieľanými prostriedkami, pripojená k sieti Po analyzovaní niekoľkých IS základnú úroveň bezpečnosti IS. by sa malo zvážiť, či možno stanoviť celo firemnú Ďalšou možnosťou výberu opatrení bez podrobného zvažovania je použiť základné úrovne špecifické pre aplikácie. Napríklad sú dostupné základné manuály riešenia bezpečnosti IS pre telekomunikácie, zdravotnú starostlivosť, bankovníctvo a mnohé ďalšie. Pri používaní týchto manuálov je napríklad možné preveriť existujúce alebo plánované opatrenia a skontrolovať odporúčané. Avšak pred vybraním konkrétnych opatrení pre implementáciu je stále osožné podrobnejšie preskúmať bezpečnostné potreby alebo záujmy. 215

216 Ohodnotenie bezpečnostných požiadaviek a hrozieb Ďalej opísaný výber opatrení podľa bezpečnostných záujmov a hrozieb možno použiť nasledovne: Prvým krokom je identifikovať a ohodnotiť bezpečnostné záujmy organizácie/ spoločnosti/podniku. Mali by sa posúdiť požiadavky na dôvernosť, integritu, dostupnosť, zodpovednosť, autenticita a spoľahlivosť. Sila a počet vybraných opatrení by mali byť primerané ohodnoteným bezpečnostným záujmom. Ďalej sa pre každú z bezpečnostných požiadaviek uvedú typické hrozby a pre každú hrozbu sa navrhnú bezpečnostné opatrenia v závislosti na posudzovanom IS Poznámka: Rôzne typy systémov IT sú predstavené v odseku 7.1 a prehľad možných opatrení je uvedený napríklad v pododsekoch odseku 8, štandardu ISO/IEC TR 13335, Časť 4. Pre efektívny výber vhodných opatrení je potrebné pochopiť bezpečnostné záujmy podnikových operácií podporovaných posudzovaným systémom IT. S pomocou identifikácie bezpečnostných záujmov, berúc do úvahy relevantné hrozby, ktoré by mohli ohroziť tieto záujmy, môžu byť vybrané vhodné bezpečnostné opatrenia. Informácie pre podporu uvedených faktov možno nájsť v odseku 11, štandardu ISO/IEC TR 13335, Časť 4. Bezpečnostné obavy/záujmy môžu zahŕňať: stratu dôvernosti, stratu integrity, stratu dostupnosti, stratu zodpovednosti, stratu autenticity a stratu spoľahlivosti. Tam, kde sú všetky možné straty dôvernosti, integrity, dostupnosti, zodpovednosti, autenticity a spoľahlivosti identifikované len ako pravdepodobne spôsobiace malé škody, dostatočnú bezpečnosť pre posudzovaný IS by mal poskytnúť prístup popísaný nižšie. Ak sa identifikuje, že ktorákoľvek z týchto strát by mohla pravdepodobne spôsobiť vážne škody, malo by sa zhodnotiť vybranie dodatočných opatrení k tým, ktoré sú uvedené v odsekoch 10.2 až ISO/IEC TR 13335, Časť Strata dôvernosti Posúďte, aké škody by mohli vzniknúť z (úmyselnej alebo neúmyselnej) straty dôvernosti posudzovaného aktíva (aktív). Strata dôvernosti môže napríklad viesť ku: strate dôvery verejnosti alebo pokazeniu verejného imidžu spoločnosti; právnym záväzkom, vrátane tých, ktoré môžu vzniknúť z porušenia legislatívy na ochranu dát; negatívnym účinkom na politiku organizácie; 216

217 ohrozeniu osobnej bezpečnosti; finančným stratám. Na základe odpovedí na uvedené otázky by sa malo rozhodnúť, či by celkové škody, ktoré môžu vyplynúť zo straty dôvernosti, boli vážne, malé alebo žiadne. Toto rozhodnutie by malo byť zdokumentované Strata integrity Posúďte, aké škody by mohli nastať z (úmyselnej alebo neúmyselnej) straty integrity posudzovaných aktív. Strata integrity by mohla viesť napríklad k: prijímaniu nesprávnych rozhodnutí, podvodu, narušeniu podnikateľského procesu, strate dôvery verejnosti alebo pokazeniu verejného imidžu, finančnej strate a právnym záväzkom, vrátane tých, ktoré môžu vzniknúť z porušenia legislatívy na ochranu napr. osobných dát. Na základe odpovedí na uvedené otázky by sa malo rozhodnúť, či by celkové škody, ktoré môžu vyplynúť zo straty dôvernosti, boli vážne, malé alebo žiadne. Toto rozhodnutie by malo byť zdokumentované Strata dostupnosti Posúďte, aké škody by mohli vzniknúť z inej ako krátkodobej straty dostupnosti aplikácií alebo informácií, t.j. ktoré podnikové funkcie by po prerušení dostupnosti dát neboli dokončené včas. Mala by sa posúdiť aj extrémna forma straty dostupnosti, trvalá strata dát a/alebo fyzické zničenie hardvéru alebo softvéru. Strata dostupnosti kritických aplikácií alebo informácií by mohla viesť napríklad k: prijímaniu nesprávnych rozhodnutí, neschopnosti vykonávať kritické úlohy, strate dôvery verejnosti alebo zničeniu verejného imidžu, finančným stratám, právnym záväzkom, vrátane tých, ktoré môžu vzniknúť z porušenia legislatívy na ochranu dát a z nedodržania zmluvných termínov, značným nákladom na obnovu. Je dôležité poznamenať, že škody vyplývajúce zo straty dostupnosti môžu významne kolísať z hľadiska rôzneho časového trvania nedostupnosti dát. Tam, kde toto platí, je vhodné posúdiť všetky škody, ktoré by mohli nastať počas takýchto rôznych časových období a zhodnotiť škody pre každé časové obdobie ako vážne, malé alebo žiadne (tieto informácie by sa mali potom použiť pri výbere opatrení). Na základe odpovedí na uvedené otázky by sa malo rozhodnúť, či by celkové škody, ktoré by mohli vyplynúť zo straty dostupnosti, boli vážne, menšie alebo žiadne. Toto rozhodnutie by malo byť zdokumentované. 217

218 Strata zodpovednosti Posúďte, aké škody by mohli vzniknúť zo straty zodpovednosti za činnosti používateľov, systémov alebo subjektov (napr. softvéru) konajúcich v mene používateľa. Toto posudzovanie by malo zahŕňať aj automaticky generované správy, ktoré môžu spôsobiť výskyt určitej činnosti. Strata zodpovednosti môže napríklad viesť k: manipulácii systémom používateľmi, podvodu, priemyselnej špionáži, nesledovateľným činnostiam, falošným obvineniam právnym záväzkom, vrátane tých, ktoré by mohli vzniknúť z porušenia legislatívy na ochranu dát. Na základe odpovedí na uvedené otázky by sa malo rozhodnúť, či by celkové škody, ktoré by mohli vzniknúť zo straty zodpovednosti, boli vážne, menšie alebo žiadne. Toto rozhodnutie by malo byť zdokumentované Strata autenticity Posúďte, aké škody by mohli vzniknúť zo straty autenticity dát a správ, bez ohľadu na to, či sú využívané ľuďmi alebo systémami. Je to obzvlášť dôležité v distribuovaných systémoch, kde sú prijaté rozhodnutia distribuované širokej komunite alebo kde sa používajú referenčné informácie. Strata autenticity by mohla viesť napríklad k podvodu, použitiu neplatných dát v platnom procese, čo by viedlo k zavádzajúcemu výsledku, manipulácii organizácie z vonka, priemyselnej špionáži, falošným obvineniam, právnym záväzkom, vrátane tých, ktoré by mohli vzniknúť z porušenia legislatívy na ochranu dát. Na základe odpovedí na uvedené otázky by sa malo rozhodnúť, či by celkové škody, ktoré by mohli vzniknúť zo straty autenticity, boli vážne, menšie alebo žiadne. Toto rozhodnutie by malo byť zdokumentované Strata spoľahlivosti Posúďte, aké škody by mohli vzniknúť zo straty spoľahlivosti systémov. Je dôležité posudzovať funkcionalitu, ktorá je sub-charakteristikou spoľahlivosti (pozri ISO 9126). Strata spoľahlivosti by mohla viesť napríklad k: podvodu, strate podielu na trhu, demotivácii pracovníkov, nespoľahlivým dodávateľom, strate dôvery zákazníkov, 218

219 právnym záväzkom, vrátane tých, ktoré by mohli vzniknúť z porušenia legislatívy na ochranu dát. Na základe odpovedí na uvedené otázky by sa malo rozhodnúť, či by celkové škody, ktoré by mohli vzniknúť zo straty spoľahlivosti, boli vážne, menšie alebo žiadne. Toto rozhodnutie by malo byť zdokumentované. 219

220 Výber bezpečnostných opatrení pre pokrytie bezpečnostných záujmov Bezpečnostné opatrenia pre dôvernosť (utajenie) V ďalšom texte sú uvedené typy hrozieb, ktoré by mohli ohroziť dôvernosť, spolu s opatreniami na ochranu voči pomenovaným hrozbám. Poznámka: Uvádzané hrozby nie sú zoradené podľa abecedy. o Odpočúvanie, o Elektromagnetická radiácia, o Zlomyseľný kód, o Predstieranie identity používateľa, o Nesprávne smerovanie/presmerovanie správ, o Zlyhanie softvéru. Hrozba: Odpočúvanie Jedným zo spôsobov získania prístupu k citlivým informáciám je odpočúvanie, napríklad odpočúvanie linky alebo načúvanie telefónnej konverzácii. Protiopatrenia: Fyzické opatrenia: Týmito môžu byť miestnosti, steny, budovy, atď., ktoré robia odpočúvanie nemožným alebo ťažko realizovateľným. Ďalším spôsobom je pridanie šumov. V prípade telefónov môže určitú ochranu voči odpočúvaniu zabezpečiť vhodná kabeláž. Politika bezpečnosti IT: Ďalším spôsobom ako sa vyhnúť odpočúvaniu, je mať prísne pravidlá o tom kedy, kde a kade bude prebiehať výmena citlivých informácií. Ochrana dôvernosti dát: Ďalším spôsobom ochrany voči odpočúvaniu je zašifrovanie správy pred jej vyslaním. Hrozba: Elektromagnetická radiácia Elektromagnetická radiácia môže byť využitá útočníkom na získanie poznatkov o informáciách spracovávaných IS. Protiopatrenia: Fyzické opatrenia: Môže nimi byť použitie ochranných plášťov pre miestnosti, steny, atď., ktoré neumožňujú elektromagnetickej radiácii preniknúť za plášte; Ochrana dôvernosti dát: Je treba si uvedomiť, že táto ochrana sa aplikuje len pokiaľ sú informácie zašifrované a nie pre informácie, ktoré sú spracovávané, zobrazované alebo tlačené. Použitie prostriedkov IT s nízkou radiáciou: Je možné získať vybavenie so vstavanou ochranou. 220

221 Hrozba: Zlomyseľný kód Zlomyseľný kód môže viesť ku strate dôvernosti, napr. prostredníctvom zachytenia a odkrytia hesiel. Protiopatrenia: Ochrana voči zlomyseľnému kódu: Podrobný opis ochrany voči zlomyseľnému kódu nájdete v ISO/IEC 13335, Časť 4, odsek Ošetrovanie incidentov: Skoré oznámenie všetkých neobvyklých incidentov môže obmedziť škody v prípade útokov zlomyseľného kódu. Na detekciu pokusov o získanie vstupu do systému alebo siete možno použiť detekciu narušenia. Hrozba: Predstieranie identity používateľa Predstieranie identity používateľa možno použiť na obídenie autentizácie a všetkých služieb a s tým spojených bezpečnostných funkcií. Toto môže následne viesť k problémom s dôvernosťou, kedykoľvek toto predstieranie umožní prístup k citlivým informáciám. Protiopatrenia: I&A: Predstieranie sa stane zložitejším, ak sa aplikujú opatrenia I&A založené na kombináciách niečoho známeho, niečoho vlastneného, rovnako ako na vrodených charakteristikách používateľov Riadenie a audit logického prístupu: Riadenie logického prístupu nemôže rozlišovať medzi autorizovaným používateľom a niekým, kto predstiera tohto autorizovaného používateľa, ale používanie mechanizmov riadenia prístupu môže zmenšiť oblasť dopadu. Kontrola a analýza auditných záznamov môže zistiť vyskytujúce sa neautorizované aktivity. Ochrana voči zlomyseľnému kódu: Keďže jedným zo spôsobov zmocnenia sa hesiel je zavedenie zlomyseľného kódu na zachytenie hesiel, ochrana voči takémuto softvéru by mala byť inštalovaná. Sieťový manažment: Ďalším spôsobom zmocnenia sa citlivého materiálu je predstieranie používateľa pri výmene, napr. ov. ISO v súčasnosti pracuje na niekoľkých dokumentoch obsahujúcich ďalšie informácie o podrobných opatreniach pre sieťovú bezpečnosť. Ochrana dôvernosti dát: Ak z nejakého dôvodu vyššie spomenutý typ ochrany nie je možný alebo je nedostatočný, dodatočnú ochranu možno zabezpečiť použitím zašifrovania obsahu pamätí s citlivými dátami. Hrozba: Nesprávne smerovanie/presmerovanie správ Nesprávne smerovanie správ môže byť úmyselné alebo neúmyselné, zatiaľ čo presmerovanie sa môže uskutočniť pre dobré aj zlé účely. Presmerovanie sa môže napríklad uskutočňovať pre udržiavanie integrity a dostupnosti. Nesprávne smerovanie a presmerovanie správ môže viesť ku strate dôvernosti, ak umožní neautorizovaným osobám prístup k týmto správam. Protiopatrenia: Sieťový manažment: Opatrenia na ochranu voči nesprávnemu smerovaniu a presmerovaniu možno nájsť v iných dokumentoch, ktoré ISO aktuálne pripravuje a ktoré budú obsahovať ďalšie informácie o podrobných opatreniach pre sieťovú bezpečnosť. Ochrana dôvernosti dát: Aby sa predišlo neautorizovanému prístupu v prípade výskytu nesprávneho smerovania alebo presmerovania, správy je možné zašifrovať. 221

222 Hrozba: Zlyhanie softvéru Zlyhania softvéru môžu ohroziť dôvernosť, ak tento softvér chráni dôvernosť, napríklad softvér riadenia prístupu alebo šifrovania alebo ak zlyhanie softvéru spôsobí štrbinu, napr. v operačnom systéme. Protiopatrenia: Ošetrovanie incidentov: Každý, kto si všimne poruchu/nefunkčnosť softvéru, by to mal oznámiť zodpovednej osobe, aby sa mohli čo najskôr vykonať potrebné kroky. Viac informácií o tom možno nájsť v odseku štandardu ISO/IEC TR 13335, Časť 4. Otázky prevádzky: Niektorým zlyhaniam softvéru možno predísť kompletným testovaním softvéru pred jeho používaním a prostredníctvom riadenia zmien softvéru Bezpečnostné opatrenia pre integritu V ďalšom texte sú uvedené typy hrozieb, ktoré by mohli ohroziť integritu, spolu s opatreniami na ochranu voči pomenovaným hrozbám. Hrozby: o Opotrebenie pamäťových médií, o Chyba údržby, o Zlomyseľný kód, o Predstieranie identity používateľa, o Nesprávne smerovanie/presmerovanie správ, o Nepopierateľnosť, o Zlyhanie softvéru, o Porucha dodávky (prúdu, klimatizácie), o Technické zlyhanie, o Chyby pri prenose, o Neautorizovaný prístup k počítačom, dátam, službám a aplikáciám, o Používanie neautorizovaných programov a dát, o Neautorizovaný prístup k pamäťovým médiám, o Chyba používateľa. Hrozba: Opotrebenie pamäťových médií Opotrebenie pamäťových médií ohrozuje integritu čohokoľvek, čo je na nich uložené. Protiopatrenia: Riadenie médií: Dostatočné riadenie médií zahŕňa verifikáciu integrity, ktorá zisťuje, či boli alebo neboli uložené súbory poškodené. Zálohy: Mali by byť vytvárané zálohy všetkých dôležitých súborov, obchodných dát, atď. Ak sa zistí strata integrity, napr. prostredníctvom riadenia médií alebo počas testovania záloh, mala by sa použiť záloha alebo predošlá generácia zálohy na obnovenie integrity súborov. Ochrana integrity dát: Na ochranu integrity uložených dát možno použiť kryptografické prostriedky. Hrozba: Chyba údržby Ak sa údržba nevykonáva pravidelne alebo sa počas procesu údržby urobia chyby, integrita všetkých súvisiacich informácií je ohrozená. 222

223 Protiopatrenia: Údržba: Správna údržba je najlepším spôsobom vyhnutia sa chybám údržby. Zahŕňa to dokumentované a verifikované procedúry údržby a primeraný dohľad nad prácou vykonávanou servisným technikom. Zálohy: Ak sa vyskytli chyby údržby, na obnovu integrity poškodených informácií je možné použiť zálohy. Ochrana integrity dát: Na ochranu integrity informácií možno použiť kryptografické prostriedky. Hrozba: Zlomyseľný kód Zlomyseľný kód môže viesť ku strate integrity, napr. ak sú dátové súbory zmenené osobou, ktorá získava neautorizovaný prístup pomocou zlomyseľného kódu, alebo zlomyseľným kódom samotným. Protiopatrenia: Ochrana voči zlomyseľnému kódu: Použitie prostriedkov antivírusovej ochrany. Ošetrovanie incidentov: Včasné oznamovanie všetkých neobvyklých incidentov môže obmedziť škody v prípade útokov zlomyseľného kódu. Na zistenie pokusov o získanie prístupu do systému alebo siete možno použiť detekciu narušenia. Hrozba: Predstieranie identity používateľa Predstieranie identity používateľa možno použiť na obídenie autentizácie a všetkých služieb a bezpečnostných funkcií s tým spojených. Následne to môže viesť k problémom s integritou, kedykoľvek toto predstieranie umožní prístup a modifikáciu informácií. Protiopatrenia: I&A: Predstieranie sa stane zložitejším, ak sú aplikované opatrenia I&A založené na kombináciách niečoho známeho, niečoho vlastneného, rovnako ako na vrodených charakteristikách používateľov Riadenie a audit logického prístupu: Riadenie logického prístupu nemôže rozlišovať medzi autorizovaným používateľom a niekým vydávajúcim sa za tohto autorizovaného používateľa, ale používanie aplikovaných mechanizmov riadenia prístupu môže znížiť oblasť dopadu Kontrola a analyzovanie auditných záznamov vytváraných IS ( OS, SRBD, aplikáciami,...) môžu zistiť neautorizované aktivity. Ochrana voči zlomyseľnému kódu: Keďže jedným zo spôsobov zmocnenia sa hesiel je zavedenie zlomyseľného kódu na zachytenie hesiel, mala by byť inštalovaná ochrana voči takémuto softvéru Sieťový manažment: Ďalším spôsobom neautorizovaného prístupu je predstierať používateľa pri výmene, napr. ov. ISO v súčasnosti pracuje na niekoľkých dokumentoch obsahujúcich ďalšie informácie o podrobných opatreniach pre sieťovú bezpečnosť. Ochrana integrity dát: Ak vyššie uvedený typ ochrany z nejakého dôvodu nie je možný, alebo nie je dostatočný, dodatočnú ochranu možno zabezpečiť použitím kryptografických prostriedkov ako sú digitálne podpisy. 223

224 Hrozba: Nesprávne smerovanie/presmerovanie správ Nesprávne smerovanie je úmyselné alebo neúmyselné nesprávne smerovanie správ, zatiaľ čo presmerovanie sa môže uskutočniť pre dobré aj zlé účely. Presmerovanie sa môže napríklad vykonávať na údržbu integrity a dostupnosti. Nesprávne smerovanie a presmerovanie správ môže viesť k strate integrity, napríklad ak sú správy zmenené a potom poslané pôvodnému adresátovi. Protiopatrenia: Sieťový manažment: Opatrenia na ochranu voči nesprávnemu smerovaniu a presmerovaniu možno nájsť v iných dokumentoch, ktoré ISO v súčasnosti vytvára a ktoré budú obsahovať ďalšie informácie o podrobných opatreniach pre sieťovú bezpečnosť. Ochrana integrity dát: Aby sa predišlo neautorizovanému zmeneniu v prípade nesprávneho smerovania a presmerovania, možno použiť hašovacie funkcie a digitálne podpisy. Hrozba: Nepopierateľnosť Opatrenia pre nepopierateľnosť by mali byť aplikované vtedy, keď je dôležité mať dôkaz o tom, že určitá správa bola poslaná a/alebo prijatá a že sieť správu preniesla. Protiopatrenia: Ako základ pre zaistenie nepopierateľnosti existujú špecifické kryptografické opatrenia. Hrozba: Zlyhanie softvéru Zlyhania softvéru môžu zničiť integritu dát a informácií, ktoré sú pomocou tohto softvéru spracovávané. Protiopatrenia: Oznamovanie nefunkčností softvéru: Čo najskoršie oznamovanie nesprávnej funkčnosti softvéru pomáha obmedzovať škody v prípade zlyhaní softvéru. Otázky prevádzky: Testovanie softvéru možno použiť na zabezpečenie toho, aby softvér fungoval správne a riadením zmien softvéru možno predísť spôsobeniu softvérových problémov z dôvodu aktualizácií alebo iných softvérových zmien. Zálohy: Zálohy, napríklad ich predošlá generácia, môžu byť použité na obnovu integrity dát, ktoré boli spracovávané softvérom, ktorý nefunguje správne. Ochrana integrity dát: Na ochranu integrity informácií môžu byť použité kryptografické prostriedky. Hrozba: Porucha dodávky (prúdu, klimatizácie) Výpadky prúdu môžu spôsobiť problémy s integritou, ak sú nimi spôsobené iné výpadky. Poruchy dodávky môžu napríklad viesť k zlyhaniam hardvéru, technickým zlyhaniam alebo k problémom s pamäťovými médiami. Protiopatrenia: Prúd a klimatizácia: Tam, kde je potrebné vyhnúť sa akýmkoľvek problémom vyplývajúcim z porúch dodávky, by sa mali používať vhodné opatrenia týkajúce sa dodávky prúdu a klimatizácie, napr. prepäťová ochrana a záložný zdroj energie. Zálohy: Na obnovu akýchkoľvek informácií, ktoré boli poškodené, by sa mali používať zálohy. 224

225 Hrozba: Technické zlyhanie Technické zlyhania, napríklad v sieti, môžu zničiť integritu akýchkoľvek informácií, ktoré sú uložené alebo spracovávané v tejto sieti. Protiopatrenia: Otázky prevádzky: Na vyvarovanie sa zlyhaní akéhokoľvek IS alebo siete by sa mal využívať manažment konfigurácií a zmien, rovnako ako kapacitný manažment. Na zaistenie bezproblémového chodu systému alebo siete sa používa dokumentácia a údržba. Sieťový manažment: Prevádzkové procedúry, plánovanie systému a riadna konfigurácia siete by sa mali používať na minimalizovanie rizík technických zlyhaní. Prúd a klimatizácia: Tam, kde je to potrebné, by sa mali používať vhodné opatrenia týkajúce sa dodávky prúdu a klimatizácie, ako je napr. prepäťová ochrana a záložný zdroj energie, aby sa predišlo akýmkoľvek problémom vyplývajúcim zo zlyhania dodávky. Zálohy: Zálohy by sa mali používať na obnovu akýchkoľvek informácií, ktoré boli poškodené. Hrozba: Chyby pri prenose Chyby pri prenose môžu zničiť integritu prenášaných informácií. Protiopatrenia: Kabeláž: Starostlivé plánovanie prenosovej kapacity a uloženie káblov môže predísť chybám prenosu, napríklad ak je chyba spôsobená preťažením (pozri aj 8.1.7). Manažment sietí: Prostriedky siete by mali byť náležite prevádzkované a udržiavané, aby sa predišlo chybám prenosu. ISO aktuálne pracuje na niekoľkých dokumentoch obsahujúcich ďalšie informácie o podrobných opatreniach pre sieťovú bezpečnosť, ktoré možno použiť proti chybám prenosu. Ochrana integrity dát: Na ochranu voči náhodným chybám pri prenose možno použiť kontrolné súčty alebo cyklické redundantné kódy v komunikačných protokoloch. Pre prípad úmyselných útokov možno na ochranu integrity prenášaných dát použiť kryptografické prostriedky. Hrozba: Neautorizovaný prístup k počítačom, dátam, službám a aplikáciám Neautorizovaný prístup k počítačom, dátam, službám a aplikáciám môže byť hrozbou pre integritu týchto informácií, ak je možná neautorizovaná modifikácia. Protiopatrenia: Riadenie a audit logického prístupu: Opatrenia popísané v odseku štandardu ISO/IEC TR 13335, časť 4., by sa mali používať na zabezpečenie riadenia logického prístupu prostredníctvom využitia mechanizmov riadenia prístupu. Preverovanie a analyzovanie auditných záznamov môžu zistiť neautorizované aktivity vykonávané ľuďmi s prístupovými právami do systému. Oddelenie sietí: Aby sa sťažil neautorizovaný prístup, malo by sa aplikovať oddelenie (segregácia) sietí (pozri 8.2.4). Riadenie fyzického prístupu: Okrem riadenia logického prístupu možno ochranu dát zabezpečiť fyzickou ochranou prístupu (pozri 8.1.7). Riadenie médií: Ak sú citlivé dáta uložené na iných médiách (napr. pružných diskoch), na ochranu daných médií pred neautorizovaným prístupom by sa malo aplikovať riadenie médií. 225

226 Integrita dát: Na ochranu integrity informácií, ktoré sú uložené alebo prenášané možno použiť kryptografické prostriedky. Hrozba: Používanie neautorizovaných programov a dát Používanie neautorizovaných programov a dát ohrozuje integritu informácií uložených a spracovávaných v príslušnom IS, ak sú dané programy a dáta používané na modifikovanie informácií neautorizovaným spôsobom alebo ak používané programy a dáta obsahujú zlomyseľný kód (napr. hry). Protiopatrenia: Bezpečnostné povedomie a zácvik: Všetci zamestnanci by si mali byť vedomí faktu, že by nemali inštalovať a používať žiadny softvér bez povolenia bezpečnostného manažéra IS. Zálohy: Zálohy by sa mali používať na obnovu akýchkoľvek informácií, ktoré boli poškodené. I&A: Na prevenciu neautorizovaného prístupu by sa mali používať vhodné opatrenia I&A v kombinácii s riadením logického prístupu. Riadenie a audit logického prístupu: Riadením logického prístupu, ako je opísané v odseku štandardu ISO/IEC TR 13335, Časť 4., by malo zabezpečiť, aby len autorizované osoby mohli použiť softvér na spracovanie a modifikovanie informácií. Kontrolovanie a analyzovanie auditných záznamov môžu zistiť neautorizované aktivity. Ochrana pred zlomyseľným kódom: Všetky programy a dáta by mali byť pred použitím preverené z hľadiska prítomnosti zlomyseľného kódu. Hrozba: Neautorizovaný prístup k pamäťovým médiám Neautorizovaný prístup k pamäťovým médiám a ich používanie môžu ohroziť integritu, pretože umožňujú neautorizovanú modifikáciu informácií uložených na týchto médiách. Protiopatrenia: Otázky prevádzky: Riadenie médií možno použiť napríklad na fyzickú ochranu a zodpovednosť za médiá, s cieľom predísť neautorizovanému prístupu a verifikovaniu integrity, ako aj na zistenie narušenia integrity uložených na médiách. Mala by sa navrhnúť zvláštna starostlivosť na ochranu ľahko prenosných médií, ako sú pružné disky, zálohové pásky, USB tokeny a papier. Fyzická bezpečnosť: Vhodná ochrana miestností (silné steny a okná, rovnako ako riadenie fyzického prístupu) a bezpečnostný nábytok môžu chrániť voči neautorizovanému prístupu. Integrita dát: Kryptografické prostriedky možno použiť na ochranu integrity informácií uložených na médiách. 226

227 Hrozba: Chyba používateľa Používateľské chyby môžu narušiť integritu informácií. Protiopatrenia: Bezpečnostné povedomie a zácvik: Všetci používatelia by mali byť primerane vyškolení, aby sa vyhli používateľským chybám pri spracovávaní informácií. Toto by malo zahŕňať nácvik definovaných procedúr pre špecifické činnosti, ako sú prevádzkové alebo bezpečnostné procedúry. Zálohy: Zálohy, napríklad predošlá generácia, môžu byť použité na obnovu integrity informácií, ktoré boli zničené z dôvodu používateľských chýb Bezpečnostné opatrenia pre dostupnosť V ďalšom texte sú uvedené typy hrozieb, ktoré by mohli ohroziť dostupnosť, spolu s opatreniami na ochranu voči pomenovaným hrozbám. Hrozby: o Deštruktívny útok, o Opotrebenie pamäťových médií, o Zlyhanie komunikačných prostriedkov a služieb, o Požiar, voda, o Chyba údržby, o Zlomyseľný kód, o Predstieranie identity používateľa, o Nesprávne smerovanie/presmerovanie správ, o Zneužitie prostriedkov, o Prírodné pohromy, o Zlyhania softvéru, o Výpadok dodávky (prúdu, klimatizácie), o Technické zlyhania, o Krádež, o Prenosové preťaženie, o Chyby pri prenose, o Neautorizovaný prístup k počítačom, dátam, službám a aplikáciám, o Používanie neautorizovaných programov a dát, o Neautorizovaný prístup k pamäťovým médiám, o Chyba používateľa. Bezpečnostné protiopatrenia sú ďalej uvádzané len pre tie hrozby, ktoré neboli doposiaľ opisované. 227

228 Hrozba: Deštruktívny útok Informácie môžu byť zničené deštruktívnymi útokmi. Protiopatrenia: Disciplinárny proces: Všetci zamestnanci by si mali byť vedomí následkov, ak (úmyselne alebo neúmyselne) zničia informácie. Riadenie médií: Všetky médiá by mali byť vhodne chránené pred neautorizovaným prístupom, použitím fyzickej ochrany a osobnej zodpovednosti za všetky médiá. Zálohy: Mali by sa vytvárať zálohy všetkých dôležitých súborov, obchodných dát, atď. Ak určitý súbor alebo akákoľvek iná informácia nie sú dostupné (z akéhokoľvek dôvodu), na obnovenie tejto informácie by mala byť použitá záloha alebo predošlá generácia zálohy. Ochrana materiálu: Malo by sa využívať riadenie fyzického prístupu na predchádzanie akémukoľvek neautorizovanému prístupu, ktorý by napomohol neautorizovanému zničeniu prostriedkov IT alebo informácií. I&A: Na predchádzanie neautorizovanému prístupu by sa mali používať vhodné opatrenia I&A v kombinácii s riadením logického prístupu. Riadenie a audit logického prístupu: Riadenie logického prístupu, ako je opísané v odseku ISO/IEC TR 13335, Časť 4 by malo zaistiť, aby sa nemohol uskutočniť žiadny neautorizovaný prístup k informáciám, umožňujúci zničenie týchto informácií. Preverovanie a analyzovanie auditných záznamov môže zistiť neautorizované aktivity. Hrozba: Zlyhanie komunikačných prostriedkov a služieb Zlyhanie prostriedkov a komunikačných služieb ohrozuje dostupnosť informácií prenášaných prostredníctvom týchto služieb. V závislosti na tom, čo spôsobilo výpadok, môže byť nápomocné zvážiť aj: Zlyhanie softvéru, Výpadok dodávky, Technickú chyba. Protiopatrenia: Duplicitný HW a zálohy: Duplicitná implementácia komponentov komunikačných služieb môže byť využitá na zníženie pravdepodobnosti zlyhaní komunikačných služieb. V závislosti na maximálnom prijateľnom trvaní výpadku možno tiež na splnenie požiadaviek použiť záložné prostriedky. V každom prípade by mali byť zálohované dáta o konfigurácii a usporiadaní, aby sa zaistila ich dostupnosť v prípade núdze. Manažment sietí: ISO v súčasnosti pracuje na niekoľkých dokumentoch obsahujúcich ďalšie informácie o podrobných opatreniach pre sieťovú bezpečnosť, ktoré možno aplikovať na ochranu voči zlyhaniam komunikačných prostriedkov alebo služieb. Kabeláž: Starostlivé plánovanie prenosovej kapacity a uloženie káblov môže predísť škodám. Ak existuje podozrenie, že niektorá linka by mohla byť poškodená, mala by byť preverená. Nepopierateľnosť: Ak je potrebný dôkaz o doručení po sieti alebo o odoslaní alebo prijatí určitej správy, mala by sa aplikovať nepopierateľnosť. Potom by mohli byť ľahko zistené komunikačné výpadky alebo chýbajúce informácie. 228

229 Hrozba: Požiar, voda Informácie a prostriedky IT môžu byť zničené ohňom a/alebo vodou. Protiopatrenia: Fyzická ochrana: Všetky budovy a miestnosti obsahujúce prostriedky IT alebo médiá na ktorých sú uložené dôležité informácie, by mali byť primerane chránené voči požiaru a vode. Plán nepretržitosti (kontinuity) činnosti: Kvôli ochrane podniku pred katastrofálnymi účinkami požiaru a vody by mal byť k dispozícii plán zachovania nepretržitosti činnosti a mali by byť dostupné zálohy všetkých dôležitých informácií. Hrozba: Zneužitie prostriedkov Zneužitie prostriedkov môže viesť k nedostupnosti informácií alebo služieb. Protiopatrenia: Personál: Všetok personál by si mal byť vedomý dôsledkov zneužitia prostriedkov. Ak je to potrebné, mali by byť aplikované disciplinárne procesy. Otázky prevádzky: Systém by mal byť monitorovaný kvôli zisteniu neautorizovaných aktivít a malo by byť aplikované oddelenie povinností, aby sa minimalizovali možnosti zneužitia privilégií. I&A: Mali by sa používať primerané opatrenia I&A v kombinácii s riadením logického prístupu, s cieľom predísť neautorizovanému prístupu. Riadenie a audit logického prístupu: Opatrenia v odseku štandardu ISO/IEC TR 13335, Časť 4 by sa mali používať na zabezpečenie riadenia logického prístupu k prostriedkom, prostredníctvom použitia mechanizmov riadenia prístupu. Preverovanie a analyzovanie auditných záznamov môže zistiť neautorizované aktivity. Sieťový manažment: Mala by sa aplikovať vhodná sieťová konfigurácia a segregácia, s cieľom minimalizovať možnosť zneužitia prostriedkov v sieťach Hrozba: Prírodné pohromy Pre ochranu voči strate informácií a služieb z dôvodu prírodných pohrôm by mali byť aplikované ďalej uvedené opatrenia. Protiopatrenia: Ochrana voči prírodným pohromám: Všetky budovy by mali byť čo najviac chránené voči prírodným pohromám. Plán zachovania nepretržitosti (kontinuity) činnosti: Mal by existovať plne testovaný plán zachovania nepretržitosti činnosti pre každú budovu a mali by byť dostupné zálohy všetkých dôležitých informácií, služieb a prostriedkov. 229

230 Hrozba: Krádež Krádež zjavne ohrozuje dostupnosť informácií a prostriedkov IT. Protiopatrenia: Fyzické opatrenia: Môže ísť o materiálnu ochranu, ktorá robí prístup k budove, oblasti alebo miestnosti obsahujúcej prostriedky IT a informácie zložitejším alebo špecifické opatrenia proti krádeži prostriedkov IT. Personál: Mali by byť aplikované opatrenia pre personál (preverovanie externého personálu, dohody o dôvernosti, dohody o hmotnej zodpovednosti, atď.), ktoré robia krádež zložitou. Riadenie médií: Akékoľvek médiá obsahujúce dôležitý materiál by mali byť chránené pred krádežou. Hrozba: Prenosové preťaženie Prenosové preťaženie ohrozuje dostupnosť informácií prenášaných prostredníctvom týchto služieb. Protiopatrenia: Duplicitný HW a zálohy: Duplicitná implementácia komponentov komunikačných služieb môže byť použitá na zníženie pravdepodobnosti prenosového preťaženia. V závislosti na maximálnom prijateľnom trvaní výpadku môžu byť na splnenie týchto požiadaviek použité záložné zariadenia. V každom prípade by mali byť zálohované konfiguračné dáta a dáta o usporiadaní, aby sa zaistila dostupnosť v prípade núdze. Sieťový manažment: Na predchádzanie preťaženiu sietí by sa mala používať správna konfigurácia, manažment a správa sietí a komunikačných služieb. Sieťový manažment: ISO v súčasnosti vytvára dokumenty obsahujúce ďalšie informácie o podrobných opatreniach pre sieťovú bezpečnosť, ktoré možno aplikovať na ochranu voči prenosovému preťaženiu. 230

231 Bezpečnostné opatrenia pre osobnú zodpovednosť, autentickosť a spoľahlivosť Rámec osobnej zodpovednosti, autentickosti a spoľahlivosti sa v rôznych doménach výrazne líši. Tieto rozdiely znamenajú, že v praxi môžu byť aplikovateľné mnohé rôzne opatrenia. Preto v tejto oblasti je možné ďalej poskytnúť len všeobecné rady. Osobná zodpovednosť Pre ochranu (osobnej) zodpovednosti by mali byť zvážené všetky hrozby, ktoré môžu viesť k vykonaniu krokov, ktoré nemožno priradiť špecifickej entite alebo subjektu. Niektorými z príkladov takýchto hrozieb sú: o zdieľanie účtov, o nedostatok sledovateľnosti krokov, o predstieranie používateľskej identity, o zlyhanie softvéru, o neautorizovaný prístup k počítačom, dátam, službám a aplikáciám, o slabá autentizácia identity. Existujú dva typy osobnej zodpovednosti, ktoré by mali byť posúdené. Jeden typ sa týka identifikovania používateľa zodpovedného za špecifické úkony s informáciami a IS. Toto môžu zabezpečiť vytvárané auditné záznamy. Druhý typ sa týka zodpovednosti medzi používateľmi v systéme. Toto je možné dosiahnuť službami s nepopierateľnosťou zodpovednosti, rozdelením poznatkov alebo zdvojenou kontrolou. Na posilnenie osobnej zodpovednosti alebo prispenie k nej možno použiť mnoho iných opatrení. Môžu byť vhodné rôzne opatrenia od bezpečnostných politík, bezpečnostného povedomia, riadenia a auditu logického prístupu, po jednorazové heslá a riadenie médií. Predpokladom pre osobnú zodpovednosť je implementácia politiky vlastníctva informácií. Výber špecifických opatrení pre konkrétny IS bude závisieť na špecifickom používaní osobnej zodpovednosti v rámci danej domény. 231

232 Autentickosť Dôvera v autentickosť môže byť znížená akoukoľvek hrozbou, ktorá môže viesť k tomu, že osoba, systém alebo proces si nie sú istí, či určitý objekt je tým, čím sa zdá byť. Niektorými z príkladov hrozieb, ktoré môžu viesť ku vzniku takejto situácie sú: o neriadené zmeny dát, o nepreverený pôvod dát, o neudržiavaný zdroj dát. Na posilnenie autentickosti alebo na prispenie k nej môžu byť využité mnohé opatrenia. Môžu byť použiteľné opatrenia od využívania označených referenčných dát, riadenia a auditu logického prístupu, po používanie digitálnych podpisov. Výber špecifických opatrení pre konkrétny IS bude závislý na špecifickom využívaní autentickosti v rámci domény. Spoľahlivosť Akákoľvek hrozba, ktorá môže viesť k nekonzistentnému správaniu sa systémov alebo procesov, vyústi do obmedzenej spoľahlivosti. Niektorými príkladmi takýchto hrozieb sú: o nekonzistentný výkon systému, o nespoľahliví dodávatelia. Strata spoľahlivosti by mohla vyústiť do zlých služieb zákazníkom alebo straty dôvery zákazníkov. Na posilnenie spoľahlivosti alebo ako príspevok k nej, môžu byť použité mnohé iné opatrenia. Môžu byť vhodné opatrenia od takých, ako sú plány zachovania nepretržitosti činnosti, zavedenie redundancie do fyzickej architektúry a údržby systému, po identifikáciu, autentizáciu, ako aj riadenie a audit logického prístupu. Výber špecifických opatrení pre konkrétny IS bude závislý na špecifickom využívaní spoľahlivosti v rámci domény. Poznámka: Je vhodné uvedomiť si, že všeobecne použiteľné opatrenia poskytujú "všeobecnejšiu" ochranu, to znamená že sú zamerané na škálu hrozieb a poskytujú ochranu podporou celkovo efektívneho manažmentu bezpečnosti IT. Ich účinky by sa nemali podceňovať a mali by byť vždy v určitom rozsahu implementované pre celkovo efektívnu ochranu. 232

233 Výber opatrení podľa podrobných ohodnotení Výber opatrení podľa podrobných ohodnotení sleduje rovnaké princípy, aké sú aplikované v prípade výberu bezpečnostných protiopatrení podľa typu IS. Vykonanie podrobnej analýzy rizík umožňuje zobrať do úvahy zvláštne požiadavky a okolnosti daného IS a jeho aktív. Rozdielna od predošlých postupov je však úroveň úsilia s akou sa rieši bezpečnosť IS a podrobnosť zhromažďovaných informácií počas procesu ohodnocovania. Preto je možné kvalifikované zdôvodnenie vybraných bezpečnostných opatrení, čo v prípade uplatnenia základného prístupu k riešeniu bezpečnosti IS nie je často možné. Kapitola 13.3 týchto skrípt obsahuje opis SW nástrojov, ktoré sa v praxi využívajú pre realizácii detailnej analýzy rizík IS, ktorá vlastne vedie k výberu bezpečnostných opatrení podľa podrobných ohodnotení aktív, hrozieb, zraniteľností a rizík. IS. 233

234 15.3 Nástroje pre analýzu a manažment rizík IS Proces analýzy rizík IT je veľmi náročný z hľadiska času, ale i vedomostí personálu, ktorý ho realizuje. Je to ďalej proces veľmi zložitý, pretože musí zohľadňovať všetky aspekty ovplyvňujúce správnu a bezpečnú činnosť IT. Ďalej je to proces, ktorý nie je samoúčelný, ale musí v konečnom dôsledku viesť k praktickému zaisteniu bezpečnej prevádzky IS. To znamená, že nemôže byť vytrhnutý z kontextu celkového riadenia spoločnosti. Vzhľadom k vyššie uvedeným vlastnostiam procesu analýzy rizík je pochopiteľná snaha tento proces zrýchliť, sprehľadniť a skvalitniť pomocou špeciálnych softvérových nástrojov. Výber vhodného nástroja je rozhodujúcim faktorom pre budúcu kvalitu analýzy rizík. Vo svete sa používa veľké množstvo rôznych nástrojov pre analýzu rizík. Ďalej uvádzame stručné charakteristiky niektorých vybraných nástrojov na analýzu rizík RiskPAC Nástroj RiskPAC v 5.0 je produktom americkej firmy Computer Security Consultants, Inc. (CSCI) pracujúci pod operačným systémom MS WINDOWS. Tento produkt v Európe dodávajú: britská firma Continuity Planning Associates UK Ltd. a holandská firma Continuity Planning Associates BV. RiskPAC je expertný systém, do ktorého nie je zabudovaná umelá inteligencia, ale vyhovuje štandardnej definícii expertného systému. Je to analytický systém umožňujúci vykonávanie analýzy rizík v širokom spektre bezpečnostných hľadísk. Je vhodný pre zber bezpečnostne-relevantných informácií od širokého okruhu respondentov a zabezpečuje spracovanie veľkého množstva informácií. Umožňuje stanovenie miery a profilu počiatočných rizík a návrh bezpečnostných protiopatrení. Používa sa v situáciách, keď je potrebné vykonať tak ohodnotenie prostredia, ako aj vlastného informačného systému. Objekty, ktoré sú predmetom záujmu možno analyzovať z pohľadu jednotlivých oblastí bezpečnosti, tzv. bezpečnostných hľadísk. Jednotlivé bezpečnostné hľadiská sú jemnejšie členené na určité bezpečnostné podoblasti, tzv. rizikové kategórie. Odpovede jednotlivých respondentov nástroj RiskPAC vyhodnocuje na báze multikriteriálnych rozhodovacích funkcií. 234

235 Jednotlivým rizikovým kategóriám v rámci určitého bezpečnostného hľadiska priraďuje mieru rizika v hodnotách 1 5 (1 nízke riziko, 2 podpriemerné riziko, 3 priemerné riziko, 4 nadpriemerné riziko, 5 vysoké riziko), podľa výsledkov analýzy rizík. Zloženie systému RiskPAC RiskPAC využíva v rámci analýzy rizík tri základné položky: Dotazník (Questionnaire). Analýzu (Survey). Výstupnú zostavu (Report). Dotazník obsahuje znalostnú databázu o objekte (miestnosť, PC, aplikácia). Znalostná databáza sa skladá z otázok, ktoré sa dotýkajú daného subjektu a z možných odpovedí na otázky. RiskPAC obsahuje niekoľko typov dotazníkov. Dotazníky sa vzťahujú vždy k jednej oblasti bezpečnosti, tzv. bezpečnostnému hľadisku, napr. fyzická bezpečnosť (PHYSEC), počítačová bezpečnosť (PCSEC), bezpečnosť LAN (LANSEC), bezpečnosť WAN (WANSEC), systémová bezpečnosť (SYSSEC) a pod. Dotazníky môžu byť členené do troch úrovní otázok. Napr. PC bezpečnosť obsahuje nasledujúce úrovne: Úroveň 1 je zameraná na prostredie analyzovaného počítača, ktorý spracováva údaje. Žiada informácie o fyzických aspektoch počítačového vybavenia informácie o miestnosti, prístup do miestnosti, teplota a pod. Ďalej žiada zoznam procesorov, ktoré sa v tomto systéme používajú. Úroveň 2 je zameraná na procesory alebo komponenty počítačového systému. Získavajú sa údaje o výrobcovi, pamäti, komunikačných portoch, operačnom systéme a kontrolách systémových prístupov pre každý procesor, ktorý je definovaný v predchádzajúcej úrovni prostredia. V tejto úrovni sa ďalej požaduje zoznam aplikácií, ktoré sa používajú na určitom procesore. Úroveň 3 sa zameriava na aplikácie, ktoré bežia na každom procesore. Vyžadujú sa odpovede na otázky o podstate, funkcii, kritickom stave a citlivosti každej aplikácie, ktorá je definovaná na úrovni procesora. Otázky dotazníka sú zatriedené do rizikových kategórií. RiskPAC zvlášť ohodnotí každú rizikovú kategóriu a výsledky bezpečnostnej analýzy obsahujú ohodnotenie rizík pre jednotlivé rizikové kategórie vyjadrené pomocou stupnice 1 5. Prehľad rizikových kategórií využívaných pre PHYSEC je napríklad nasledovný: konštrukcia budovy dohľad nad prístupom do budovy monitorovacie systémy elektrická sieť ochrana pred ohňom a ďalšie. 235

236 Analýza predstavuje vyplnený dotazník v závislosti na zvolenom bezpečnostnom hľadisku. Získa sa tak prehľad o počiatočnej miere a profile rizika v danej oblasti informačného systému, napr. bezpečnostne - relevantné informácie o fyzickom prostredí systému, technickom vybavení, aplikácii a pod. Výstupné zostavy RiskPAC umožňuje vytvárať rôznorodé výstupné zostavy, ktoré pomáhajú analyzovať riziká a slabiny v každej hierarchickej úrovni analýzy. RiskPAC vytvára osem rôznych správ, ktoré: Opisujú riziko pre každý objekt, identifikovaný v jednotlivej analýze (survey). Sumarizujú riziká objektov vo všetkých 3 úrovniach. Poskytujú bezpečnostné protiopatrenia na základe vypočítaných úrovní rizík CRAMM CRAMM (CCTA Risk Analysis and Management Method) je metodika vlády Veľkej Británie. Pod skratkou CRAMM je potrebné chápať súčasne dve odlišné veci: Metodiku predstavujúcu návod na ohodnocovanie rizík a analýzu bezpečnosti. Podporný softvérový nástroj, ktorý pomáha pri uplatnení metodiky v praxi. Prvú verziu nástroja CRAMM vyvinula vládna inštitúcia Veľkej Británie CCTA (Central Computer and Telecommunication Agency) v roku V súčasnosti je nástroj CRAMM dodávaný vo verzii 5.0. Jedná sa o 32-bitovú aplikáciu, ktorú možno používať v prostredí MS Windows. Česká verzia nástroja CRAMM-CZ 5.0 je dodávaná na inštalačnom médiu CD spolu s hardvérovým kľúčom. Existujú dva profily CRAMM: Oficiálny profil (Official Profile) pre organizácie štátneho sektora UK. Komerčný profil (Commercial Profile) pre používanie všetkými ostatnými organizáciami COBRA Pod označením COBRA sa skrýva skupina nástrojov na Analýzu rizík IS (Risk Analysis) a Posúdenie súladu stavu zabezpečenia IS (Compliance Assessment), ktorý je proklamovaný napr. v bezpečnostnej politike, s reálnym stavom zabezpečenia. 236

237 Tieto softvérové nástroje sú produktom britskej firmy C&A Systems Security Ltd. Posledná verzia (COBRA Release 3) je 32-bitová aplikácia vytvorená pomocou databázového systému Visual FoxPro, ktorá požaduje operačný systém MW Windows. COBRA pozostáva z troch základných komponentov a palety pomocných nástrojov (utilities): Konštruktér dotazníkov (Questionnaire Builder) tento komponent slúži na tvorbu dotazníkov z modulov otázok obsiahnutých v znalostnej databáze (prípadne i nových modulov vytvorených používateľom pomocou samostatného programu Module Manager, ktorý okrem toho umožňuje aj ľubovoľne modifikovať všetky časti znalostnej databázy). Dotazník fyzicky neexistuje. Existuje iba v logickej úrovni ako väzba medzi identifikátorom (názvom) dotazníka a vybranými modulmi otázok. Analyzátor rizík, resp. Analyzátor súladu (Risk Surveyor or Compliance Surveyor) tento komponent umožňuje vyplniť dotazníky vopred vytvorené pomocou Konštruktéra dotazníka. Až po vyplnení všetkých otázok daného dotazníka možno generovať výstupné zostavy. Generátor výstupných zostáv (Report Generator) tento komponent umožňuje vygenerovať výstupné zostavy pre ukončené analýzy (Survey). Výstup možno smerovať na tlačiareň, obrazovku alebo do súboru (v rôznych formátoch, napr. RTF, DOC, CSV a pod.). Výstupné zostavy sú vytvorené s dobrou grafickou úpravou a používateľ má možnosť ovplyvniť štruktúru výstupnej zostavy pomocou parametrov vložených pomocou ovládacích prvkov dialógového okna. Jednotlivé sekcie výstupnej zostavy môžu byť generované aj samostatne. Pomocné nástroje (Utilities) Systém COBRA obsahuje paletu pomocných nástrojov, ktoré umožňujú používateľovi napríklad: vytlačiť papierové verzie dotazníkov, upraviť používateľské prostredie programu (implicitné adresáre, vyfarbenie dialógových okien a pod.), nastaviť heslá, zmeniť symbol meny, atď Analýza a manažment rizík IS nástrojom CRAMM V tejto kapitole uvádzam opis realizácie hĺbkovej analýzy rizík IS, ktorá vedie k detailnému návrhu bezpečnostného skeletu IS, pričom pre každé vybrané bezpečnostné opatrenie existuje zdôvodnenie. Obecné koncepty pre analýzu a zvládanie (manažment) rizík podľa metodiky CRAMM môžu byť reprezentované jednoduchým diagramom, kde analýza rizík a zvládanie rizík sú dve súvisiace ale oddelené aktivity, ako to vidno na nasledujúcom obrázku č

238 AKTÍVA HROZBY ZRANITEĽNÉ MIESTA ANALÝZA RIZÍK RIZIKÁ ZVLÁDANIE RIZÍK BEZPEČNOSTNÉ OPATRENIA Obrázok č.15-4 Proces analýzy a zvládania rizík Analýza rizík zahŕňa identifikáciu a ohodnotenie úrovní (mier) rizík vypočítaných zo stanovených hodnôt aktív a z ohodnotených úrovní hrozieb a zraniteľností daných aktív. Zvládanie (manažment) rizík zahŕňa identifikáciu, výber a schválenie bezpečnostných opatrení určených na redukciu rizík na akceptovateľnú úroveň, stanovených na základe zistených úrovní rizík. Pri používaní nástroja CRAMM sa proces analýzy rozčleňuje do troch základných, relatívne samostatných ale vzájomne previazaných fáz: Fáza 1 Identifikácia a ohodnotenie aktív; Fáza 2 Analýza hrozieb a zraniteľností (výpočet rizík); Fáza 3 Návrh bezpečnostných opatrení. Fáza 1 Identifikácia a ohodnotenie aktív Najprv je potrebné identifikovať aktíva, ktoré budú predmetom analýzy. Výberu aktív musí predchádzať presné vymedzenie hraníc analýzy častí systému, ktoré budú podrobené analýze a služieb poskytovaných používateľom. Aktívami potom budú všetky komponenty IS hardvér (počítače, tlačiarne, komunikačné prostriedky a pod.), aplikačný softvér, dáta, lokality (budovy, miestnosti) potrebné pre zabezpečenie používateľských služieb. Príručka používateľa nástroja obsahuje klasifikáciu jednotlivých typov aktív, spolu s charakteristikou aktív patriacich do jednotlivých typov. Ďalej je potrebné určiť vzájomné väzby existujúce medzi špecifikovanými aktívami prostredníctvom modelu systému (aktív). 238

239 Po vytvorení modelu aktív je potrebné stanoviť ich hodnotu. Pre fyzické aktíva je hodnota determinovaná finančnou sumou potrebnou na ich náhradu. Hodnota softvérových a dátových aktív je stanovená na základe dopadov straty vzniknutej ich nedostupnosťou, krádežou, modifikáciou alebo zničením. Pre určenie veľkosti týchto strát poskytuje metodika CRAMM návod. Fáza 2 Analýza hrozieb a zraniteľností (výpočet rizík) Prvým krokom v tejto fáze je zoskupenie aktív na základe odhadu pôsobenia rovnakých hrozieb na viac aktív. Ďalším krokom je priradenie jednotlivých hrozieb skupinám aktív, t. j. určenie hrozieb, ktoré budú skúmané v súvislosti s každou definovanou skupinou aktív. Príručka používateľa nástroja obsahuje priradenie hrozieb jednotlivým typom aktív a potenciálne dopady spôsobené jednotlivými hrozbami. Po priradení hrozieb skupinám aktív je potrebné hrozby a zraniteľnosti ohodnotiť. CRAMM vygeneruje sadu dotazníkov, pomocou ktorých respondenti zodpovedaním otázok určujú úrovne hrozieb a zraniteľností. Po stanovení úrovní hrozieb (stupnica: Very Low, Low, Medium, High, Very High), zraniteľností (stupnica: Low, Medium, High) a hodnôt aktív (Fáza 1) možno vypočítať miery rizík. Výpočet prebieha automaticky a je časovo náročný, pretože jeho základom sú maticové operácie, pričom rozmery matíc sú dané počtom aktív, hrozieb a zraniteľností. Výsledkom výpočtu sú miery rizík pôsobiace na jednotlivé aktíva. Miery rizík sú vypočítané na základe stupnice 1 7. Fáza 3 Návrh bezpečnostných opatrení CRAMM automaticky vygeneruje, na základe vlastnej knižnice bezpečnostných opatrení (viac ako 3000 opatrení), všetky bezpečnostné opatrenia, ktoré pripadajú do úvahy pre dané typy aktív systému. Výber prebieha na základe porovnania bezpečnostnej úrovne priradenej každému opatreniu v knižnici (reprezentuje minimálnu úroveň miery rizika, ktorú musí určité aktívum dosiahnuť pre konkrétnu hrozbu, aby bolo dané opatrenie vybrané na jeho ochranu) a vypočítaných mier rizík pre jednotlivé aktíva systému, ktorého bezpečnosť je riešená. Tieto fázy sú ešte doplnené o podporné funkcie zamerané na plánovanie kontinuity činnosti po havárii, zostavenie bezpečnostnej politiky, špecifikáciu bezpečnostných požiadaviek, tvorbu výstupných správ pre manažment organizácie o čiastkových a celkových výsledkoch analýzy, modelovanie Čo ak, a pod. 239

240 Nástroj CRAMM vo verzii 5.0 obsahuje aj modul, ktorý sa využíva na podporu vytvorenia a udržiavania ISMS podľa štandardu BS 7799, Časť 2. Tento modul podporuje najmä tieto činnosti: Vytvorenie politiky informačnej bezpečnosti, Vytvorenie dokumentácie ISMS, Vedenie záznamov analytikov, Vykonanie analýzy stavu implementácie štandardu v praxi, Prípravu Programu zvýšenia úrovne bezpečnosti, Prípravu prehlásenia o aplikovaní bezpečnostných opatrení, Previazanie analýz rizík IS s budovaním ISMS. 240

241 16 Bezpečnostná dokumentácia IS Platná legislatíva, ako aj medzinárodné štandardy pre informačnú bezpečnosť definujú rôzne požiadavky na bezpečnostnú dokumentáciu informačných systémov. Všeobecne platný zoznam jednotlivých druhov bezpečnostnej dokumentácie IS môže byť nasledovný: Bezpečnostná politika IS, Bezpečnostný zámer, Bezpečnostný projekt, Bezpečnostné smernice, Havarijný plán a plán obnovy činnosti Bezpečnostná politika IS Dokument bezpečnostnej politiky V odbornej literatúre, dostupnej na svetovom trhu, existuje rad odporúčaní z hľadiska obsahu bezpečnostnej politiky IS. Ďalej pre potreby vytvorenia dostatočného zázemia na vysvetlenie problematiky bezpečnostných politík IS, uvádzame niekoľko príkladov obsahu takejto bezpečnostnej politiky. Štandard ISO/IEC TR 13335, časť 1, v kapitole 7.2 uvádza nasledovné tvrdenie týkajúce sa odporúčaného obsahu dokumentu bezpečnostnej politiky IS: Bezpečnostná politika systému musí odrážať bezpečnostné zásady a smernice obsiahnuté v bezpečnostnej politike IT spoločnosti. Mala by obsahovať podrobnosti špecifických bezpečnostných požiadaviek a ochranných opatrení, ktoré majú byť implementované a návod ako ich správne používať, aby bola zaistená adekvátna bezpečnosť. Vo všetkých prípadoch je dôležité, aby prijatý prístup bol efektívny v relácií k obchodným potrebám spoločnosti. Vzťahy medzi jednotlivými politikami existujúcimi v spoločnosti vyjadrené obrázkom č nasledovne: sú v tomto štandarde 241

242 Obrázok č Vzťahy medzi cieľmi, stratégiami a politikami spoločnosti Celá spoločnosť Ciele Stratégia - Politika Bezpečnosť celej spoločnosti Finančná stránka celej spoločnosti Bezpečnosť IT celej spoločnosti Personálna bezpečnosť celej spoločnosti Bezpečnosť IS (1) Ciele Stratégia - Politika Bezpečnosť IS (n) Ciele Stratégia - Politika Ciele, stratégie a politiky bezpečnosti IS predstavujú to, čo sa očakáva od systému pokiaľ ide o bezpečnosť. Ciele, stratégie a politiky bezpečnosti IS sú obvykle vyjadrené pomocou prirodzeného jazyka, ale môže existovať požiadavka na ich vyjadrenie formálnejším spôsobom pomocou niektorého matematického jazyka. Mali by riešiť problémy bezpečnosti IS ako sú: dôvernosť, integrita, individuálna zodpovednosť, autenticita a spoľahlivosť. Ciele, stratégia a politika určia v spoločnosti úroveň bezpečnosti, hraničný limit pre akceptáciu rizika a požiadavky spoločnosti v prípade nepredvídaných udalostí. 242

243 Štandard ISO/IEC TR 13335, časť 2 v kapitole 8.3 uvádza: Tam, kde je to vhodné, môže byť politika bezpečnosti IT spoločnosti zahrnutá v škále technických a riadiacich politík spoločnosti, ktoré spolu tvoria základňu pre formuláciu stratégie IT spoločnosti. Táto formulácia by mala obsahovať určité presvedčivé vyjadrenia o dôležitosti bezpečnosti, najmä ak je bezpečnosť nevyhnutná pre dosiahnutie zhody s danou stratégiou. Nižšie uvedený obrázok č ukazuje vzťahy medzi rôznymi politikami spoločnosti. Bez ohľadu na dokumentáciu a organizačnú štruktúru ktorú spoločnosť používa, je dôležité aby rôzne poslania popísaných politík boli realizované a aby sa udržiavala konzistentnosť. Obchodná politika spoločnosti, odvodená od cieľov a stratégie Marketingová politika spoločnosti Bezpečnostná politika spoločnosti Politika IT spoločnosti Bezpečnostná politika IT Politika bezpečnosti IT oddelení systému B Bezpečnostná politika systému A Obrázok č Vzťahy politík 243

244 Štandard ISO/IEC TR 13335, časť 2 v kapitole 12 uvádza: Zásady vyvinuté pre bezpečnosť IS by mali byť založené na bezpečnostnej politike spoločnosti a oddelenia. Tieto politiky musia byť implementované aplikovaním vhodných bezpečnostných opatrení na systémy a služby, s cieľom zabezpečiť dosiahnutie primeranej úrovne ochrany. Politiky bezpečnosti IS musia byť schválené najvyšším manažmentom organizácie/spoločnosti/podniku ako záväzné sady princípov a pravidiel, aby sa zaistilo, že sú pre ich aplikovanie a uplatňovanie k dispozícii finančné a ľudské zdroje. Kľúčovými otázkami na zváženie pri určovaní každej bezpečnostnej politiky IS sú: definovanie hodnoteného IS a jeho hraníc; definovanie podnikových cieľov, ktoré majú byť docielené prostredníctvom daného systému, keďže tieto môžu mať vplyv na bezpečnostnú politiku systému a na výber a implementáciu bezpečnostných opatrení; potenciálne negatívne dopady na spoločnosť z nedostupnosti, odoprenia alebo zničenia služieb alebo aktív IS vrátane informácií, neautorizovanej modifikácie informácií alebo softvéru, a neautorizovaného prezradenia informácií s kvantitatívnymi následkami, ako sú priame alebo nepriame peňažné straty, rovnako ako kvalitatívne následky, ako strata dobrej reputácie, strata alebo ohrozenie života, narušenie osobného súkromia; úroveň investovania do IT; významné hrozby pre IS a v ňom držané informácie; zraniteľnosti, vrátane slabín, ktoré ponechávajú systém v ohrození identifikovanými hrozbami; potrebné bezpečnostné opatrenia, ktoré sú primerané identifikovaným rizikám; náklady na bezpečnosť IS, t.j. výdavky na ochranu aktív IS (náklady na bezpečnosť IS by mali byť považované za súčasť nákladov vlastníctva IS); vzťah k poskytovateľom externých zdrojov a princípy ich výberu (napr. výpočtové strediská, podpora PC). Bezpečnosť IS vyžaduje uplatňovať plánovaný prístup a nemala by byť riešená v izolácii. Mala by figurovať v procese strategického plánovania., zaistiac tak, že bezpečnosť je plánovaná a projektovaná do systému od začiatku. Vo väčšine situácií bude nákladnejšie alebo aj nepraktickejšie pridávať dodatočné bezpečnostné opatrenia neskôr už za prevádzky daného systému. Príklad obsahu bezpečnostnej politiky IS ako písomného dokumentu je znázornený obrázkom č nasledovne: 244

245 Obrázok č Príklad obsahu bezpečnostnej politiky IS ako písomného dokumentu 1. Úvod Bezpečnostná politika IS 2. Vymedzenie uvažovaného systému a jeho hraníc 3. Definícia cieľov (ktoré sa chcú dosiahnuť pomocou daného systému a ktoré môžu mať vplyv na návrh bezpečnostného skeletu) 4. Potenciálne nepriaznivé dopady na spoločnosť v dôsledku nefunkčnosti IS nedostupnosť, odmietnutie alebo deštrukcia služieb alebo aktív vrátane informácií neautorizovaná modifikácia informácií a softvéru neautorizované prezradenie informácií s kvantifikovaním následkov 5. Úroveň investícií do IT v rámci predmetného IS 6. Významné hrozby pre systém a spracovanie informácií 7. Zraniteľnosť zahŕňajúca slabé miesta vyskytujúce sa v systéme, vystavujúce IT identifikovaným rizikám 8. Bezpečnostné riziká, potenciálne ohrozujúce systém a ich finančné ohodnotenie 9. Akceptovateľné zostatkové riziká systému 10. Požadované kategórie bezpečnostných opatrení úmerné identifikovaným rizikám 11. Náklady na bezpečnosť ako výdavky na ochrany aktív IS 12. Vzájomné vzťahy a princípy výberu poskytovateľov vonkajších zdrojov. 13. Záver 245

246 Štandard ISO/IEC 17799: 2005 v kapitole 3.1 uvádza: Manažment by mal prostredníctvom vydania politiky informačnej bezpečnosti stanoviť jasný smer politiky a demonštrovať svoju podporu a angažovanosť z hľadiska informačnej bezpečnosti a udržovanie politiky informačnej bezpečnosti v celej spoločnosti. Dokument danej politiky by mal byť schválený manažmentom, publikovaný a primerane daný na vedomie všetkým zamestnancom. Mal by stanovovať angažovanosť manažmentu a vytyčovať prístup organizácie k riadeniu informačnej bezpečnosti. Prinajmenšom by mal obsahovať: a) definíciu informačnej bezpečnosti, jej celkové ciele, účel a dôležitosť bezpečnosti ako mechanizmu umožňujúceho spoločné používanie informácií; b) vyhlásenie zámerov manažmentu, podpory cieľov a princípov informačnej bezpečnosti; c) stručné vysvetlenie bezpečnostnej politiky, princípov, štandardov a požiadaviek na dodržiavanie, ktoré majú pre spoločnosť zvláštnu dôležitosť, napríklad: 1) dodržiavanie legislatívnych a zmluvných požiadaviek, 2) požiadavky na bezpečnostné vzdelávanie, 3) prevencia a detekcia vírusov a iného škodlivého softvéru, 4) riadenie kontinuity činnosti organizácie, 5) následky porušení bezpečnostnej politiky, d) definíciu všeobecných a špecifických zodpovedností z hľadiska riadenia informačnej bezpečnosti, vrátane ohlasovania bezpečnostných incidentov; e) odkazy na dokumentáciu podporujúcu danú politiku, napr. detailnejšie bezpečnostné pravidlá a procedúry pre špecifické informačné systémy alebo bezpečnostné pravidlá, ktoré by mali používatelia dodržiavať. S touto politikou by mali byť oboznámení používatelia v rámci celej organizácie, a to formou, ktorá je patričná, dostupná a pochopiteľná pre čitateľa. Politika by mala mať vlastníka, ktorý je zodpovedný za jej údržbu a revízie podľa definovaného procesu revízie. Tento proces by mal zaistiť, že revízia sa udeje ako odozva na akékoľvek zmeny, ktoré majú vplyv na bázu pôvodného ohodnotenia rizík, ako sú napr. významné bezpečnostné incidenty, nové zraniteľnosti alebo zmeny organizačnej alebo technickej infraštruktúry. Taktiež by mali byť naplánované periodické revízie: a) efektívnosti politiky demonštrovanej povahou, počtom a dopadom zaznamenaných bezpečnostných incidentov; b) nákladov a dopadu opatrení na efektivitu spoločnosti; c) vplyvov technologických zmien. 246

247 16.2 Bezpečnostný zámer IS Bezpečnostný zámer IS je ďalším z rady dokumentov, ktoré sú legislatívou a praxou vyžadované. Je potrebné povedať, že medzinárodné štandardy týkajúce sa informačnej bezpečnosti tento druh dokumentu nevyžadujú. Na druhej strane napríklad zákon č. 428/2002 Z.z. o ochrane osobných údajov v 16 uvádza: 16 Bezpečnostný projekt (1) Bezpečnostný projekt vymedzuje rozsah a spôsob technických, organizačných a personálnych opatrení potrebných na eliminovanie a minimalizovanie hrozieb a rizík pôsobiacich na informačný systém z hľadiska narušenia jeho bezpečnosti, spoľahlivosti a funkčnosti. (2) Bezpečnostný projekt sa spracúva v súlade so základnými pravidlami bezpečnosti informačného systému, vydanými bezpečnostnými štandardmi, právnymi predpismi a medzinárodnými zmluvami, ktorými je Slovenská republika viazaná. (3) Bezpečnostný projekt obsahuje najmä a) bezpečnostný zámer, b) analýzu bezpečnosti informačného systému, c) bezpečnostné smernice. (4) Bezpečnostný zámer vymedzuje základné bezpečnostné ciele, ktoré je potrebné dosiahnuť na ochranu informačného systému pred ohrozením jeho bezpečnosti a obsahuje najmä a) formuláciu základných bezpečnostných cieľov a minimálne požadovaných bezpečnostných opatrení, b) špecifikáciu technických, organizačných a personálnych opatrení na zabezpečenie ochrany osobných údajov v informačnom systéme a spôsob ich využitia, c) vymedzenie okolia informačného systému a jeho vzťah k možnému narušeniu bezpečnosti, d) vymedzenie hraníc určujúcich množinu zvyškových rizík. 247

248 16.3 Bezpečnostný projekt Prehľad známych požiadaviek na bezpečnostný projekt IS, ako písomný dokument, by tiež mohol byť pomerne rozsiahly. Je potrebné taktiež povedať, že bezpečnostný projekt IS je tiež typ dokumentu, ktorý je skôr vyžadovaný platnou legislatívou ako medzinárodnými štandardmi týkajúcimi sa informačnej bezpečnosti. Pre ilustrovanie existujúcej situácie ďalej uvádzam požiadavky na bezpečnostné projekty, ktoré vyplývajú zo zákonov o ochrane osobných údajov a ochrane utajovaných skutočností, platných na území SR. Zákon č. 428/2002 Z.z. o ochrane osobných údajov v znení neskorších predpisov v 15 a 16 uvádza: 15 Zodpovednosť za bezpečnosť osobných údajov (1) Za bezpečnosť osobných údajov zodpovedá prevádzkovateľ a sprostredkovateľ tým, že ich chráni pred odcudzením, stratou, poškodením, neoprávneným prístupom, zmenou a rozširovaním. Na tento účel prijme primerané technické, organizačné a personálne opatrenia zodpovedajúce spôsobu spracúvania. (2) Opatrenia podľa odseku 1 prijme prevádzkovateľ a sprostredkovateľ vo forme bezpečnostného projektu informačného systému (ďalej len bezpečnostný projekt ) a zabezpečí jeho vypracovanie, ak a) informačný systém je prepojený na verejne prístupnú počítačovú sieť alebo je prevádzkovaný v počítačovej sieti, ktorá je prepojená na verejne prístupnú počítačovú sieť, b) sú v informačnom systéme spracúvané osobitné kategórie osobných údajov ( 8), alebo c) informačný systém podlieha výnimkám uvedeným v 2 ods. 2. (3) Na požiadanie úradu prevádzkovateľ a sprostredkovateľ preukážu rozsah a obsah prijatých technických, organizačných a personálnych opatrení podľa odseku 1 alebo

249 16 Bezpečnostný projekt (1) Bezpečnostný projekt vymedzuje rozsah a spôsob technických, organizačných a personálnych opatrení potrebných na eliminovanie a minimalizovanie hrozieb a rizík pôsobiacich na informačný systém z hľadiska narušenia jeho bezpečnosti, spoľahlivosti a funkčnosti. (2) Bezpečnostný projekt sa spracúva v súlade so základnými pravidlami bezpečnosti informačného systému vydanými bezpečnostnými štandardmi, právnymi predpismi a medzinárodnými zmluvami, ktorými je Slovenská republika viazaná. (3) Bezpečnostný projekt obsahuje najmä a) bezpečnostný zámer, b) analýzu bezpečnosti informačného systému, c) bezpečnostné smernice. Zákon č. 215/2004 o ochrane utajovaných skutočností v 58 uvádza: 58 Bezpečnostný projekt na technické prostriedky (1) Bezpečnostný projekt na technické prostriedky určuje rozsah a spôsob ich použitia a prostriedky a metódy ochrany utajovaných skutočností, ktoré sa na technických prostriedkoch vytvárajú, kopírujú, inak rozmnožujú, spracúvajú, prenášajú, ukladajú alebo uchovávajú. (2) Bezpečnostný projekt na technické prostriedky obsahuje a) bezpečnostný zámer; b) opis technických prostriedkov; c) analýzu ochrany utajovaných skutočností z hľadiska straty, narušenia utajenia, dostupnosti, integrity a autentickosti utajovaných skutočností, klasifikovanie hlavných hrozieb pre utajované skutočnosti, možné protiopatrenia na jednotlivé hrozby z hľadiska prevencie, detekcie a eliminácie; d) použitie bezpečnostných štandardov a určenie iných použitých metód a prostriedkov ochrany utajovaných skutočností; e) špecifikáciu hrozieb zabezpečených opatreniami na ochranu a ich účinnosť; f) špecifikáciu hrozieb nezabezpečených opatreniami na ochranu; g) smernicu pre havarijné plánovanie a obnovu činnosti technického prostriedku alebo systému. 249

250 (3) Na ochranu technických prostriedkov a systémov, ak to umožňuje ich charakter, sa používajú systémové prostriedky s odporúčaným bezpečnostným nastavením alebo metódy a prostriedky ochrany podľa vydaných bezpečnostných štandardov. (4) Úrad sa splnomocňuje na vydanie všeobecne záväzného právneho predpisu, ktorým ustanoví podrobnosti o spracúvaní bezpečnostného projektu na technické prostriedky a o vydávaní a používaní bezpečnostných štandardov. Na základe uvedených a ďalších poznatkov je možné konštatovať, že zatiaľ čo Bezpečnostná politika IS je rozpracovaním bezpečnostných opatrení, ktoré budú tvoriť bezpečnostný skelet daného informačného systému, avšak len do úrovne špecifikácie druhov a typov bezpečnostných opatrení, ktoré budú využité, potom Bezpečnostný projekt IS rozpracováva uvedený problém do úrovne potrebnej pre samotnú realizáciu v praxi. Odporúčaný obsah Bezpečnostného projektu IS, ako písomného dokumentu je znázornený obrázkom č.16-4 nasledovne: 250

251 Obrázok č Obsah Bezpečnostného projektu IS Bezpečnostný projekt IS 1. Úvod - dôvod vypracovania - väzba na bezpečnostnú politiku IS 2. Ciele bezpečnostnej politiky IS alt. bezpečnostného zámeru 3. Vymedzenie IS 3.1. Opis architektúry IS 3.2. Funkčný opis IS 3.3. Klasifikácia dát a dokumentácie z hľadiska nutnej ochrany 3.4. Špecifikácia hrozieb, zraniteľných miest a rizík 4. Riešenie bezpečnosti IS ako celku 4.1. Prierezové oblasti bezpečnosti 4.2. Oblasti bezpečnosti riešené individuálne 5. Bezpečnosť funkčných a systémových celkov 5.1. Centrálny výpočtový systém 5.2. Záložný výpočtový systém 5.3. Uzly siete 5.4. Koncové pracoviská siete 5.5. Komunikačné trasy 5.6. Vývojové pracovisko 5.7. Externí používatelia systému Poznámka: Uvádzané členenie IS je potrebné brať ako príklad. 6. Bezpečnosť prepojení systému s inými IS 6.1. Prehľad IS a IT využívaných spoločnosťou, majúcich väzby s riešeným systémom 6.2. Riešenie bezpečnosti vzájomných prepojení 6.3. Postup overovania bezpečnosti prepojení 7. Ekonomika realizácie bezpečnostného projektu - za jednotlivé funkčné a systémové celky a za IS ako integrovaný celok 8. Harmonogram realizácie projektu 9. Záver 10. Prílohy 251

252 16.4 Bezpečnostné smernice Bezpečnostné smernice vo všeobecnosti obsahujú pravidlá, dodržiavaním ktorých sa pri prevádzke IS dosahuje jeho požadované bezpečnosť. Existuje široká paleta odporúčaní týkajúcich sa bezpečnostných smerníc pre prevádzku IS vyplývajúcich tak z medzinárodných štandardov, ako aj platnej legislatívy. Napríklad zákony o ochrane osobných údajov a ochrane utajovaných skutočností, ako aj zákon o elektronickom podpise presne definujú svoje požiadavky, ktoré okruhy musia byť pokryté bezpečnostnými smernicami. Na druhej strane je na konkrétnom riešiteľovi a prevádzkovateľovi IS, aby ich usporiadali do práve najvhodnejšej zostavy. Je ale dôležité, aby vytvorená zostava smerníc pokrývala všetky požadované okruhy. Pre ilustráciu uvádzam požiadavky na bezpečnostné smernice v skôr spomínaných zákonoch. Zákon č. 428/2002 o ochrane osobných údajov v znení neskorších predpisov v. 16, ods. (6) uvádza: (6) Bezpečnostné smernice upresňujú a aplikujú závery vyplývajúce z bezpečnostného projektu na konkrétne podmienky prevádzkovaného informačného systému a obsahujú najmä a) opis technických, organizačných a personálnych opatrení vymedzených v bezpečnostnom projekte a ich využitie v konkrétnych podmienkach, b) rozsah oprávnení a opis povolených činností jednotlivých oprávnených osôb, spôsob ich identifikácie a autentizácie pri prístupe k informačnému systému, c) rozsah zodpovednosti oprávnených osôb a osoby zodpovednej za dohľad nad ochranou osobných údajov ( 19), d) spôsob, formu a periodicitu výkonu kontrolných činností zameraných na dodržiavanie bezpečnosti informačného systému, e) postupy pri haváriách, poruchách a iných mimoriadnych situáciách vrátane preventívnych opatrení na zníženie vzniku mimoriadnych situácií a možností efektívnej obnovy stavu pred haváriou. 252

253 Zákon č. 215/2004 o ochrane utajovaných skutočností v 58 uvádza: 58 Bezpečnostný projekt na technické prostriedky (1) Bezpečnostný projekt na technické prostriedky určuje rozsah a spôsob ich použitia a prostriedky a metódy ochrany utajovaných skutočností, ktoré sa na technických prostriedkoch vytvárajú, kopírujú, inak rozmnožujú, spracúvajú, prenášajú, ukladajú alebo uchovávajú. (2) Bezpečnostný projekt na technické prostriedky obsahuje a) bezpečnostný zámer, b) opis technických prostriedkov, c) analýzu ochrany utajovaných skutočností z hľadiska straty, narušenia utajenia, dostupnosti, integrity a autentickosti utajovaných skutočností, klasifikovanie hlavných hrozieb pre utajované skutočnosti, možné protiopatrenia na jednotlivé hrozby z hľadiska prevencie, detekcie a eliminácie, d) použitie bezpečnostných štandardov a určenie iných použitých metód a prostriedkov ochrany utajovaných skutočností, e) špecifikáciu hrozieb zabezpečených opatreniami na ochranu a ich účinnosť, f) špecifikáciu hrozieb nezabezpečených opatreniami na ochranu, g) smernicu pre havarijné plánovanie a obnovu činnosti technického prostriedku alebo systému. Vyhláška NBÚ č. 541/2002 Z.z. o obsahu a rozsahu prevádzkovej dokumentácie vedenej certifikačnou autoritou a o bezpečnostných pravidlách a pravidlách na výkon certifikačných činností uvádza: 9 Bezpečnostné pravidlá (1) Bezpečnostné pravidlá akreditovanej certifikačnej autority obsahujú a) bezpečnostnú politiku, b) bezpečnostný zámer, c) bezpečnostný projekt, d) havarijný plán, e) bezpečnostné smernice. 253

254 14 Bezpečnostné smernice (1) Bezpečnostné smernice sú predpisy akreditovanej certifikačnej autority, ktoré rozpracúvajú ustanovenia bezpečnostného zámeru do procedúr a pracovných postupov záväzných pre všetkých zamestnancov certifikačnej autority. (2) Bezpečnostné smernice upravujú najmenej tieto bezpečnostné opatrenia: a) umiestnenie a používanie kryptografického zariadenia certifikačnej autority, b) riadenie prístupu ku kryptografickému zariadeniu certifikačnej autority, c) postup zálohovania dát a skladovania médií so záložnými kópiami údajov, d) postupy pri haváriách a poruchách produktu pre elektronický podpis, haváriách a poruchách infraštruktúry ohrozujúcich činnosť produktu pre elektronický podpis, jeho bezpečnosť, ako aj bezpečnosť záložných kópií údajov, ako aj pri haváriách a poruchách ohrozujúcich autenticitu a integritu poskytovaných certifikačných služieb, e) zabezpečenie prevádzky kryptografického zariadenia certifikačnej autority v núdzových alebo havarijných stavoch, f) zásady práce s médiami, g) tvorbu a vyhodnocovanie prevádzkových záznamov v písomnej alebo elektronickej forme, h) správu bezpečnostných prostriedkov, i) zásady bezpečného správania sa užívateľov a správcov produktu pre elektronický podpis, j) zisťovanie bezpečnostných incidentov a ich riešenie, k) monitorovanie a odhaľovanie nepovolených aktivít v produkte pre elektronický podpis, l) bezpečnostné procedúry spojené s výkonom certifikačných činností. 254

255 16.5 Havarijný plán a plán obnovy činnosti Štandard ISO/IEC TR 13335, Časť 1 v kapitole č.9.8 uvádza: Havarijné plány obsahujú informácie o tom, ako sa má prevádzkovať obchodná činnosť v prípade, že sú podporné procesy, vrátane IS, poškodené alebo sú nedostupné. Tieto plány by mali riešiť možné kombinácie niekoľkých scenárov zahrňujúce: rôznu dobu prerušenia, stratu rôznych typov prostriedkov, úplnú stratu fyzického prístupu k budovám a potrebu návratu do stavu, ktorý by existoval, keby nedošlo k prerušeniu. Plány obnovy pre nepredvídané udalosti opisujú ako obnoviť činnosť IS oplyvneného nežiaducim incidentom. Plány obnovy po nepredvídanej udalosti zahrňujú: kritéria, ktoré definujú nepredvídanú udalosť, zodpovednosť za aktivaciu plánu obnovy, zodpovednosť za rôzne činnosti obnovy a popis týchto činnosti. Štandard ISO/IEC 17799:2005 v kapitole 11 uvádza: Proces manažmentu kontinuity činnosti spoločnosti by sa mal implementovať s cieľom obmedziť prerušenie spôsobené haváriami a bezpečnostnými zlyhaniami (ktoré môžu vzniknúť napríklad následkom prírodných pohrôm, havárií, zlyhaní zariadení a cielenými činmi) na prijateľnú úroveň, prostredníctvom kombinácie preventívnych opatrení a opatrení obnovy. Následky havárií, bezpečnostných zlyhaní a straty služieb by mali byť analyzované. Havarijné plány by sa mali vyvíjať a implementovať s cieľom, aby podnikové procesy mohli byť obnovené v rámci požadovaných časových úsekov. Také plány by mali byť udržiavané a nacvičované, aby sa stali integrálnou súčasťou všetkých ostatných manažérskych procesov. Manažment kontinuity činnosti spoločnosti by mal zahŕňať opatrenia na identifikovanie a znižovanie rizík, obmedzovanie následkov škodlivých incidentov a zaistenie včasného obnovenia základnej prevádzky. 255

256 Manažment kontinuity činnosti V rámci celej spoločnosti by mal existovať riadený proces vývoja a údržby kontinuity činnosti. Mal by spájať nasledovné kľúčové prvky riadenia kontinuity činnosti spoločnosti: a) porozumenie rizikám, ktorým organizácia čelí, z hľadiska ich pravdepodobnosti a ich dopadu, vrátane identifikácie a stanovenia priorít kritických podnikových procesov; b) porozumenie následkom, ktoré prerušenia pravdepodobne budú mať, na spoločnosť (je dôležité nájsť riešenia menších incidentov, rovnako ako vážnych incidentov, ktoré by mohli ohroziť životaschopnosť organizácie) a stanovenie podnikových cieľov pre prostriedky spracovávajúce informácie; c) zváženie zakúpenia vhodného poistenia, ktoré môže tvoriť súčasť procesu kontinuity činnosti; d) formulovanie a dokumentovanie stratégie kontinuity činnosti spoločnosti, konzistentnej s odsúhlasenými podnikovými cieľmi a prioritami; e) formulovanie a dokumentovanie plánov kontinuity činnosti spoločnosti v súlade s odsúhlasenou stratégiou; f) pravidelné testovanie a aktualizovanie existujúcich plánov a procesov; g) zaistenie, aby riadenie kontinuity činnosti spoločnosti bolo včlenené do procesov a štruktúry organizácie. Zodpovednosť za koordinovanie procesu riadenia kontinuity činnosti by mala byť pridelená na primeranej úrovni v organizácii, napr. fóru informačnej bezpečnosti Analýza dopadov havárie na spoločnosť Kontinuita činnosti by mala začať identifikovaním udalostí, ktoré môžu spôsobiť prerušenia podnikových procesov, napr. zlyhanie zariadení, zatopenie a požiar. Toto by malo byť nasledované ohodnotením rizík, s cieľom určiť dopad daných prerušení (v zmysle rozsahu škôd, ako aj v zmysle dĺžky času obnovy). Obe tieto aktivity by mali byť vykonávané s plnou zainteresovanosťou vlastníkov podnikových zdrojov a procesov. Toto ohodnotenie by malo brať do úvahy všetky podnikové procesy a nie je obmedzené na prostriedky spracovania informácií. Na základe výsledkov ohodnotenia rizík by mal byť vytvorený strategický plán na určenie celkového prístupu ku kontinuite činnosti. Po vytvorení takéhoto plánu by tento mal byť schválený manažmentom spoločnosti. 256

257 Zostavovanie a implementovanie plánov kontinuity činnosti Mali by byť vytvárané plány udržiavania a obnovy podnikových operácií v rámci požadovaných časových intervalov po prerušení alebo zlyhaní kritických podnikových procesov. Proces plánovania kontinuity činnosti spoločnosti by mal zvažovať nasledovné: a) identifikácia a odsúhlasenie všetkých zodpovedností a núdzových procedúr; b) implementácia havarijných procedúr, s cieľom umožniť obnovenie v rámci požadovaných časových intervalov. Zvláštnu pozornosť je potrebné venovať ohodnoteniu externých závislostí podniku a existujúcim kontraktom; c) dokumentácia odsúhlasených procedúr a procesov; d) primeraná výchova pracovníkov z hľadiska odsúhlasených havarijných procedúr a procesov, vrátane krízového riadenia; e) testovanie a aktualizovanie plánov. Proces plánovania by sa mal zameriavať na požadované podnikové ciele, napr. obnovenie špecifických služieb pre zákazníkov počas prijateľného časového úseku. Mali by sa zvažovať služby a zdroje, ktoré to umožnia, vrátane personálneho zabezpečenia, ne-informačných prostriedkov spracovania, rovnako ako dohôd o zálohových postupoch pre prostriedky spracovania informácií Štruktúra plánovania kontinuity činnosti Mala by sa udržiavať jednotná štruktúra plánov kontinuity činnosti zaisťujúca, aby všetky plány boli konzistentné a identifikujúce priority testovania a údržby. Každý plán kontinuity by mal jasne špecifikovať podmienky svojej aktivácie, rovnako ako jednotlivcov zodpovedných za realizáciu každého komponentu plánu. Po identifikovaní nových požiadaviek, by sa zavedené havarijné procedúry, ako napr. evakuačné plány alebo všetky existujúce zálohové dohody, mali primerane upraviť. Štruktúra plánovania kontinuity činnosti spoločnosti by mala zahŕňať: a) podmienky aktivácie plánov, ktoré popisujú proces, ktorý je potrebné dodržať (ako vyhodnotiť situáciu, kto sa má toho zúčastniť, atď.) predtým, ako dôjde k aktivácii ktoréhokoľvek plánu; b) havarijné procedúry, opisujúce činnosti, ktoré majú byť vykonané po incidente, ktorý ohrozuje prevádzku podniku a/alebo ľudský život. Toto by malo zahŕňať dohody o riadení vzťahov s verejnosťou a o efektívnom styku s príslušnými verejnými autoritami, napr. políciou, požiarnym zborom a miestnymi správnymi orgánmi; c) zálohové procedúry opisujúce kroky, ktoré sa majú vykonať pre presunutie dôležitých podnikových aktivít alebo podporných služieb do alternatívnych 257

258 prechodných lokalít a pre umožnenie obnovenia prevádzky podnikových procesov v rámci požadovaných časových intervalov; d) procedúry návratu popisujúce činnosti, ktoré majú byť vykonané pre návrat k normálnej prevádzke; e) rozvrh údržby plánu špecifikujúci ako a kedy má byť plán testovaný a proces údržby plánu; f) aktivity v oblasti povedomia a vzdelávania, ktoré majú vytvoriť porozumenie procesom kontinuity činnosti spoločnosti a zaistiť kontinuálnu efektivitu uvedených procesov; g) zodpovednosti/povinnosti jednotlivcov opisujúce kto je zodpovedný za realizáciu ktorej zložky plánu. Ak je to potrebné, mali by byť vymenovaní náhradníci. Každý plán by mal mať špecifického držiteľa/vlastníka/správcu. Havarijné procedúry, plány o manuálnej zálohe a plány návratu, by mali patriť do zodpovednosti vlastníkov/držiteľov príslušných podnikových prostriedkov alebo súvisiacich procesov. Zálohové dohody o alternatívnych technických službách, ako sú prostriedky spracovania informácií alebo komunikačné prostriedky, by mali byť obyčajne v zodpovednosti poskytovateľov daných služieb Zostavovanie plánov obnovy činnosti Príprava podkladov pre zostavenie plánu obnovy Podklady pre zostavenie plánu obnovy sa získavajú buď pomocou vyplnenia vopred pripravených formulárov alebo priamo vkladaním získaných údajov do databázy SW nástroja používaného pre podporu aktivít spoločnosti v oblasti recovery. Údaje pre zostavenie plánu obnovy sa týkajú najmä nasledovných okruhov: Funkcie, ktorých činnosť bude obnovovaná, Pracovné skupiny, Volacie zoznamy tímov, Úlohy obnovy pre jednotlivé tímy, Požadované prostriedky, Telekomunikácie, Zmluvní dodávatelia, Zákazníci, Dôležité záznamy, Technické vybavenie, Softvér, Logistika, Nábytok, Inventárne zoznamy. 258

259 Obnovované funkcie Ich identifikácia je výsledkom BIA a schválená stratégia obnovy činnosti po havárii určí, ktoré funkcie budú zahrnuté do pripravovaného plánu obnovy. Zoznam obsahuje aj podporné počítačové aplikácie a polohu v budove. Pracovné skupiny Zoznam útvarov (úsekov, odborov, oddelení, referátov podľa platného organizačného poriadku spoločnosti a mená osôb podľa útvarov), ktorých činnosť bude obnovovaná. Volacie zoznamy tímov s telefónnymi číslami a adresami členov tímov Predstavujú vlastne zloženie jednotlivých tímov obnovy. Pre každého člena by mal byť menovaný aj jeho zástupca pre prípad, keď z akejkoľvek príčiny nebude dosiahnuteľný riadny člen tímu. Úlohy obnovy Ide vlastne o presný opis postupu akcií vykonávaných jednotlivými tímami obnovy (teda návod na činnosť). Miesto obnovy (primárne alebo náhradné pracovisko) určí Krízový manažment. Úlohy obnovy by mali pokrývať najhorší scenár. Mali by však obsahovať rozhodovania podľa momentálnej situácie, tak aby bolo možné podľa nich postupovať aj pri menšom rozsahu havárie. Požadované prostriedky Súpis technických prostriedkov, softvéru, telekomunikácií a spotrebného materiálu potrebného pri obnove jednotlivých funkcií. Je tu zahrnuté aj vybavenie, ktoré zabezpečuje normálnu činnosť funkcie. Z dôležitých záznamov (teda písomných dokumentov) len tie, ktoré sú nevyhnutne potrebné pri obnove funkcie. Telekomunikácie Zoznam telekomunikačných liniek (dátových, hlasových) zabezpečujúcich funkcie v mieste obnovy. Pre obnovu telekomunikácií je vhodné zostaviť osobitný tím. Zmluvní dodávatelia Zoznam všetkých dodávateľov, s pomocou ktorých sa počíta pri obnove (adresy, telefónne čísla, kontaktné mená). Zákazníci (Zmluvní partneri) Zoznam najdôležitejších zákazníkov, ktorí by mali byť informovaní o havárii, ako aj o priebehu jej odstraňovania. Dôležité záznamy Zoznam životne dôležitých a nevyhnutných záznamov a dokumentov na rôznych médiách, potrebných pre prežitie spoločnosti po havárii. Patria sem: všetky dokumenty a záznamy potrebné pri obnove funkcií (inštalačné médiá, manuály, konfiguračné listy a pod.); všetky dokumenty finančného hospodárstva spoločnosti, pohľadávky a záväzky. Ich rekonštrukcia nie je možná alebo je cenovo náročná, a preto musia byť uchovávané v ohňovzdorných trezoroch; 259

260 právne dokumenty vlastnícke listy, zmluvy, najmä servisné zmluvy a zmluvy o podpore pri prevádzke určitých zariadení alebo softvéru a iné právne dokumenty; iné dokumenty, ktoré spoločnosť považuje za dôležité. Hoci väčšina dôležitých záznamov môže byť uskladnená v záložnom sklade, predsa mnohé z nich sú uskladnené aj priamo v budove, ktorá môže byť zasiahnutá haváriou. V takom prípade je nutné poznať ich miesto uloženia a spôsob, ako rýchlo môžu byť vynesené zo zasiahnutého miesta, prípadne spôsob ich znovu získania. Treba adresne stanoviť kto to urobí, kam a ako ich prenesie. Záložný sklad musí vyhovovať podmienkam pre skladované záznamy (bezpečnosť, teplota, vlhkosť a pod.) Zoznam vecí skladovaných pre potrebu obnovovania činnosti po havárii by mal obsahovať: číslo a opis záznamu; typ média; dátum vzniku záznamu, jeho účel a vzťah k ostatným dokumentom; dátum platnosti; dôsledky straty dokumentu. Technické vybavenie Zoznam počítačov, prídavných zariadení a iných technických prostriedkov a zariadení potrebných pri obnove funkcií. Sem patria aj prostriedky zabezpečujúce normálnu činnosť obnovovanej funkcie. Softvér Zoznam základného softvéru a aplikácií nutných pre normálne fungovanie obnovovaných funkcií. Logistika Zoznam podporných služieb stravovacie, ubytovacie, poštovné a dopravné služby. Nábytok Minimálne vybavenie obnovovaných miestností nábytkom a iným inventárom. Inventárne zoznamy Zoznam vybavenia potrebného pre správne vybavenie miestností, v ktorých sú lokalizované jednotlivé obnovené funkcie a pre uplatnenie prípadných poistných nárokov Vytvorenie plánu obnovy Po vykonaní analýzy dopadov, schválení stratégie obnovy a príprave a zozbieraných podkladov, možno pristúpiť k vytvoreniu vlastného plánu obnovy. preverení Každý tím obnovy má svoj vlastný plán/návod činnosti, ktorý obsahuje: poslanie daného tímu; zoznam obnovovaných funkcií; 260

261 volací zoznam členov tímu; požadované prostriedky pre obnovu; plán úloh obnovy; opis úloh obnovy; prílohy (môžu byť spoločné pre všetky tímy). Väčšina tímov obnovy bude mať mnohé povinnosti počas úvodnej fázy obnovy činnosti po havárii. Od začiatku havárie, až po definitívnu obnovu všetkých funkcií na stálom pôvodnom alebo novom pracovisku, musia úlohy jednotlivých tímov obnovy korenšpondovať s rozličnými etapami obnovy. Ďalej uvedený príklad štruktúry plánu obnovy určuje 3 hlavné fázy obnovy činnosti po havárii. I keď existuje viac termínov pre pomenovanie týchto fáz, nasledovné termíny sú najpoužívanejšie: Fáza 1: časový interval začínajúci ihneď po ohlásení havárie niekedy nazývaný ako stav núdze, krízový stav alebo reakčná fáza. Fáza 2: časový interval, počas ktorého sú obnovované funkcie zahrnuté do plánu obnovy niekedy nazývaný ako obnova, reštaurácia alebo fáza obnovy. Funkcie môžu byť obnovené v tzv. minimálnej konfigurácii, ktorá zabezpečí dostatočné podmienky na vykonávanie funkcie (využitie náhradných postupov, využitie terminálov servera pokiaľ bude obnovená sieť LAN a pod.). Fáza 3: časový interval, počas ktorého je celá činnosť prenesená na stále pracovisko niekedy nazývaný ako relokácia alebo fáza návratu. Funkcie sú obnovené v plnej pôvodnej konfigurácii. Plán obnovy sa obyčajne nepodarí vytvoriť na prvý raz a tvorbu plánu obnovy treba uskutočniť minimálne v 2 až 3 cykloch, pozostávajúcich z nasledovných činností: 1. cyklus : vytvorenie prvej verzie plánu obnovy, vypracovanie plánu testovania plánu obnovy, vykonanie testov plánu obnovy, úprava plánu obnovy podľa výsledkov testov. 2. cyklus vytvorenie druhej verzie plánu obnovy, testovanie a nácvik plánu obnovy. 3. cyklus vytvorenie definitívnej verzie plánu obnovy, údržba plánu obnovy. Vzorová štruktúra plánu obnovy fiktívnej spoločnosti po havárii je znázornená nasledovným obrázkom č

262 Spoločnosť xyz Reakčná fáza Vrcholový manažment tím Krízový manažment tím Záchrana majetku a ohodnotenie škody tím Koordinácia obnovy Fáza obnovy útvar 1 tím č.1: Obnova skupiny funkcií 11 (životne dôležité, min. konfigurácia) Obnova skupiny funkcií 12 (dôležité, min. konfigurácia) útvar 2 tím č.2: Obnova skupiny funkcií 21 (životne dôležité, min. konfigurácia) Obnova skupiny funkcií 22 (dôležité, min. konfigurácia) útvar 3 tím č.3: Obnova skupiny funkcií 31 (životne dôležité, min. konfigurácia) Obnova skupiny funkcií 32 (dôležité, min. konfigurácia) Fáza návratu Riadiaci tím návratu útvar 1 tím č.1: Obnova skupiny funkcií 11 (životne dôležité, max. konfigurácia) Obnova skupiny funkcií 12 (dôležité, max. konfigurácia) Obnova skupiny funkcií 13 (ostatné) útvar 2 tím č.2: Obnova skupiny funkcií 21 (životne dôležité, max. konfigurácia) Obnova skupiny funkcií 22 (dôležité, max. konfigurácia) Obnova skupiny funkcií 23 (ostatné) útvar 3 tím č.3: Obnova skupiny funkcií 31 (životne dôležité, max. konfigurácia) Obnova skupiny funkcií 32 (dôležité, max. konfigurácia) Obnova skupiny funkcií 33 (ostatné) Podporné tímy Obrázok č. 24 Vzorový plán obnovy (štruktúra) 262

263 Reakčná fáza (stav núdze) Stav núdze je stav bezprostredne po vzniku havárie. Ak havária vznikne mimo pracovnú dobu, potom prvý, kto zistí haváriu alebo príznaky, ktoré by mohli viesť k havárii, je strážna služba. V pracovnej dobe to môže byť ktokoľvek zo zamestnancov prítomných v budove. Bezpečnostný monitorovací systém by mal byť pravidelne kontrolovaný. Ak funguje, strážna služba zistí nebezpečenstvo počas pravidelných obchôdzok areálu. Postup strážnej služby v situáciách ohrozenia určuje vnútorná havarijná smernica. Jej prvou úlohou je zamedziť šíreniu havárie. Preto musí poznať polohu hlavných uzáverov plynu a vody, polohu hlavného ističa elektrickej prípojky a pod. Ak si situácia vyžaduje pomoc požiarnych, bezpečnostných, zdravotných a iných záchranných služieb, strážna služba ich okamžite informuje a požiada o pomoc. Po vykonaní nevyhnutných opatrení informuje vedúceho krízového manažmentu spoločnosti alebo v prípade jeho nedostupnosti ktoréhokoľvek člena tímu krízového manažmentu. Zodpovedný pracovník strážnej služby uvedie vo svojej informácii svoje meno, čas zistenia havárie, doteraz vykonané opatrenia a opis momentálneho stavu. Vedúci krízového manažmentu alebo iný prítomný alebo privolaný člen tímu začne okamžite monitorovať situáciu a podľa konkrétnej situácie rozhodne o zvolaní tímu krízového manažmentu. Postupne zvolá celý tím. Podľa situácie rozhodne o aktivácii Riadiaceho centra a určí miesto stretnutia tímu Krízový manažment Riadiace centrum Tím krízového manažmentu rozhodne o ďalšom postupe pri zvládaní vzniknutej havárie. Prvou úlohou je záchrana osôb a majetku. V prípade, že je to nutné, rozhoduje o aktivácii Riadiaceho centra s nutným vybavením, odkiaľ riadi a koordinuje aktivity po havárii. Krízový manažment organizuje evakuáciu osôb, podľa potreby aktivuje tím záchrany majetku a požiada o pomoc podporné tímy. Takisto rozhodne o aktivácii príslušných tímov obnovy. V prvej informácii poskytovanej vedúcim tímov uvedie doteraz známe skutočnosti a požiada ich, aby boli v pohotovosti. Podľa situácie rozhodne aj o aktivácii záložného pracoviska. Zloženie tímu krízového manažmentu je zvyčajne nasledovné: Riaditeľ vedúci tímu, Asistent GR, Bezpečnostný manažér spoločnosti, Finančný riaditeľ zástupca vedúceho, Riaditeľ telekomunikácií, Personálny riaditeľ, Riaditeľ právneho odboru, Manažér pre styk s verejnosťou, Koordinátori obnovy. 263

264 Krízový manažment sa presunie do riadiaceho centra a zostáva tam, kým sa nevyriešia počiatočné problémy a nestanoví dlhodobá stratégia obnovy. Tím zistí rozsah havárie a odhadne potenciálne dôsledky, koordinuje a vykonáva styk s médiami a schvaľuje aktiváciu celého alebo len časti plánu obnovy. Okrem asistenta riaditeľa spoločnosti, ktorýkoľvek člen krízového manažmentu je oprávnený rozhodnúť o rozsahu a dôsledkoch havárie, aktivovať tím krízového manažmentu a implementovať celý alebo len časti plánu obnovy, ktoré opisuje obnovu zasiahnutých funkcií. Krízový manažment riadi celý proces obnovy od vzniku havárie až po ukončenie obnovy. Jeho prvou úlohou je zvládnuť najťažšiu fázu po havárii. Ak havária nastala počas pracovnej doby, najdôležitejšou úlohou je záchrana ľudí a majetku. Po stabilizovaní situácie rozhoduje o aktivácii jednotlivých tímov obnovy. Spolupracuje s externými bezpečnostnými, požiarnymi a zdravotnými službami. Informuje médiá a rodiny zamestnancov. Po celý čas obnovy naopak vedúci tímov informujú tím krízového manažmentu o stave prebiehajúcej obnovy. V kompetencii tímu krízového manažmentu je zvyčajne: stanovenie dlhodobej a krátkodobej stratégie obnovy; vedenie záznamu o činnosti; stanovenie informačnej politiky; styk so zákazníkmi; styk s dodávateľmi; styk so štátnymi úradmi; styk s bezpečnostnými, požiarnymi a zdravotnými službami; styk s verejnosťou určenie osôb s právom informovať mediálne zložky a verejnosť, učenie a zverejnenie informačnej linky (tel. číslo pre podávanie informácií o havárii a postupe obnovy); podávanie správ vedeniu spoločnosti; informovanie rodinných príslušníkov poskytnutie pomoci; stanovenie bezpečnostnej politiky; zabezpečenie areálu, posilnenie strážnej služby, mimoriadne povinnosti; schvaľovanie mimoriadnych výdavkov; schvaľovanie záverečných správ a vypracovanie celkovej záverečnej správy o priebehu a výsledkoch obnovy; monitorovanie postupu obnovy prijímanie správ od tímov obnovy, sledovanie morálneho stavu personálu; koordinovanie podporných tímov; koordinovanie záchrany majetku; 264

265 koordinovanie poistných a právnych záležitostí; koordinovanie reštaurácie primárneho pracoviska a prechodu na normálnu činnosť Záchrana majetku a ohodnotenie škody Tím pre záchranu majetku a ohodnotenie škody je aktivovaný rozhodnutím tímu krízového manažmentu. Tím začína svoju činnosť ihneď, ako mu je umožnený bezpečný vstup na miesto havárie. Zisťuje rozsah havárie a posudzuje možnosti obnovy na primárnom pracovisku. Rozhoduje o použiteľnosti technických zariadení nábytku a iného vybavenia. Určí priestor pre dočasné uskladnenie tohto materiálu a organizuje jeho presun. Pracuje na zostavení poistných nárokov. Informuje krízový manažment o rozsahu škody. Výber členov tímu by mal byť urobený starostlivo. Tím by mal byť vybavený ochrannými prostriedkami a pripravený pre havarijné podmienky. V procese zisťovania škôd tím posudzuje najmä: budovu je aspoň čiastočne použiteľná? pracovné priestory aké úpravy sú potrebné? Približný čas potrebný na renováciu? energie - je poškodená vnútorná elektrická inštalácia alebo externý prívod? Je možné použiť náhradný zdroj el. energie? telefónne spojenie interné alebo externé prerušenie liniek? Sú funkčné aspoň niektoré? dátové spoje rozsah fyzického poškodenia, je možná náhradná komunikácia? vodu je prerušená dodávka vody? kúrenie je funkčná kotolňa a rozvod tepla? klimatizáciu je aspoň čiastočne funkčná? bezpečnostný systém je funkčný? Koordinácia obnovy Tím koordinácie obnovy koordinuje styk medzi všetkými tímami obnovy. Sleduje a určuje postup obnovy. Kontaktuje dodávateľov, ak je to potrebné, a spolu s krízovým manažmentom zaisťuje efektívny priebeh a úspešné zavŕšenie obnovy činnosti spoločnosti. Ak rozsah havárie vyžaduje aktiváciu Riadiaceho centra, tím sa premiestni do Riadiaceho centra a zostane tam, kým nevznikne potreba jeho účasti na niektorom z alternatívnych miest. Tím končí svoju činnosť až po skončení obnovy všetkých funkcií. 265

266 Fáza obnovy Fáza obnovy začína aktiváciou prvého tímu obnovy. Úlohy obnovy jednotlivých tímov obnovy musia reflektovať činnosti, ktoré treba vykonať pre prenesenie základných funkcií na záložné pracovisko. Vo fáze obnovy a vo fáze návratu pôsobia rovnaké tímy obnovy. Rozdiel je len v tom, že tímy vo fáze obnovy obnovujú len životne dôležité a dôležité funkcie, aj to len v tzv. dopredu definovanej minimálnej konfigurácii, kým vo fáze návratu tímy obnovujú všetky funkcie v úplnej pôvodnej konfigurácii. Miesto obnovy môže byť na pôvodnom primárnom pracovisku alebo, ak si to situácia vyžaduje, na záložnom pracovisku, resp. na alternatívnom pracovisku. Jednotlivé útvary majú podľa potreby 1 alebo viac tímov obnovy Fáza návratu Plánovanie návratu na stále pracovisko je dôležitá súčasť plánu obnovy. Návrat musí byť koordinovaný so všetkými útvarmi, ktoré boli postihnuté haváriou. Predpokladom týchto činností je, že je kam sa vrátiť a to buď na pôvodné pracoviská alebo, ak je k dispozícii, na alternatívne miesto. Fáza návratu nie je časovo obmedzená a môže trvať aj niekoľko mesiacov. Jednotlivé tímy obnovy po ukončení fázy obnovy sa presunú na stále pracovisko a obnovia všetky funkcie v pôvodnej konfigurácii Riadiaci tím návratu Riadiaci tím návratu po obnove životne dôležitých a dôležitých funkcií, koordinuje aktivity, ktoré majú za cieľ uviesť pracovisko do stavu pripravenosti vykonávať pôvodné funkcie. Hlavné úlohy riadiaceho tímu návratu sú: vypracovanie časového plánu pre renováciu primárneho pracoviska alebo úpravu alternatívneho pracoviska.; získanie finančného krytia a výber dodávateľov ; prekonzultovanie plánu s vedením spoločnosti; monitorovanie reštauračných prác ; obnova kabeláže a telekomunikácií; inštalácia monitorovacieho zabezpečovacieho systému; objednávka technického vybavenia, telekomunikácií, nábytku, spotrebného materiálu a zabezpečenie služieb; 266

267 vypracovanie časového plánu pre aktiváciu jednotlivých tímov obnovy a pre návrat vedenia spoločnosti a všetkých útvarov na stále pracoviská; stanovenie požiadaviek na podporný tím a ďalší personál pre podporu návratu. Poznámka: Pre rozsiahlejšiu reštauráciu budovy alebo pre zaobstaranie alternatívneho pracoviska sú potrebné osobitné detailné plány, ktoré sú mimo rámec plánu obnovy Testovanie plánov Testovanie plánov kontinuity činnosti môže často zlyhať z dôvodu nesprávnych predpokladov, opomenutí alebo zmien prostriedkov alebo personálu. Preto by mali byť pravidelne testované, aby sa zaistilo, že sú aktuálne a efektívne. Takéto testy by mali tiež zaisťovať, aby všetci členovia tímu obnovy a iní relevantní pracovníci plány poznali. Rozvrh testovania plánu (plánov) kontinuity činnosti spoločnosti by mal udávať ako a kedy by mal byť testovaný každý prvok plánu. Odporúča sa testovať jednotlivé komponenty plánu (plánov) často. Na poskytnutie záruky, že plán(y) bude(ú) v reálnom živote fungovať, by sa mala používať škála techník. Tieto techniky by mali zahŕňať: a) teoretické testovanie rôznych scenárov (diskutovanie o usporiadaní obnovy činnosti za použitia príkladov narušenia); b) simulácie (najmä pre zácvik ľudí v ich post-incidentových rolách a rolách krízového riadenia); c) technické testovanie obnovy (zaisťujúce, aby informačné systémy mohli byť obnovené efektívne); d) testovanie obnovy na záložnom pracovisku (prevádzkovanie podnikových procesov paralelne s operáciami obnovy mimo hlavného pracoviska); e) testy dodávateľských prostriedkov a služieb (zaistenie toho, aby externe zabezpečené služby a produkty splnili dohody z kontraktov); f) kompletné nácviky (testujúce, či organizácia, pracovníci, zariadenia, príslušenstvo a procesy dokážu zvládnuť prerušenia). Uvedené techniky môžu byť použité akoukoľvek organizáciou a mali by odrážať povahu špecifického plánu obnovy. 267

268 Údržba a prehodnocovanie plánov Plány kontinuity činnosti by mali byť udržiavané pravidelnými revíziami a aktualizáciami, zaisťujúcimi ich kontinuálnu účinnosť. Do programu riadenia zmien organizácie by mali byť včlenené procedúry zaisťujúce primeranú pozornosť, venovanú otázkam kontinuity činnosti spoločnosti. Mala by byť určená zodpovednosť za pravidelné previerky každého plánu obnovy. Identifikácia zmien usporiadania spoločnosti, ktorá sa ešte neodrazila v plánoch kontinuity činnosti, by mala byť nasledovaná primeranou aktualizáciou plánu. Tento formálny proces riadenia zmien by mal zaisťovať, aby aktualizované plány boli distribuované a vylepšované pravidelnými previerkami kompletného plánu. Príklady situácií, ktoré by mohli vynucovať aktualizáciu plánov, zahŕňajú akvizíciu nových zariadení alebo aktualizovanie prevádzkových systémov a zmeny v: a) personáli, b) adresách alebo telefónnych číslach. 268

269 17 Manažment bezpečnosti IS vo fázach životného cyklu Ako bolo uvedené v predchádzajúcom texte skrípt, skúsenosti z praxe, ako aj medzinárodné normy týkajúce sa informačnej bezpečnosti vyžadujú, aby bezpečnosť IS bola zaistená vo všetkých fázach jeho životného cyklu. V súvislosti so splnením tejto požiadavky prebiehajú nejaké činností a vznikajú nejaké dokumenty týkajúce sa bezpečnosti IS vo všetkých fázach životného cyklu IS. Táto kapitola predstavuje zhrnutie v predchádzajúcom texte skrípt. poznatkov o riešení bezpečnosti IS uvedených 17.1 Bezpečnosť IS vo fáze plánovania a riadenia Vo väzbe na tému tejto kapitoly je na mieste otázka, či v súvislosti so zaistením bezpečnosti IS v tejto fáze životného cyklu prebiehajú nejaké špecifické procesy týkajúce sa bezpečnosti IS a či vznikajú nejaké ďalšie dokumenty alebo bezpečnosť IS musí byť nejako zahrnutá do skôr spomínaných dokumentov. Odpoveď je nasledovná: Zaistenie bezpečnosti IS počas životného cyklu vyžaduje, aby v rámci fázy Plánovania a riadenia : d) tvorca Inovačného zámeru špecifikoval aj zámer z hľadiska bezpečnosti predmetného IS, v rozsahu ako je to možné; e) tvorca Štúdie IS špecifikoval aj možné varianty zaisťovania bezpečnosti predmetného IS, v rozsahu ako je to možné; f) tvorca Plánu budovania IS naplánoval procesy, ktoré budú realizované v súvislosti s riešením bezpečnosti IS. Splnenie tejto požiadavky sa nezaobíde bez spolupráce s budúcim prevádzkovateľom IS a bezpečnostným manažérom predmetného IS. Zhrnutie: Z uvedeného textu vypláva, že v súvislosti s riešením bezpečnosti IS nie je potrebné do fázy zaradiť ďalšie činností a výstupné dokumenty. Riešenie bezpečnosti IS by malo prebiehať v rámci pôvodne definovaných činností a návrhy na riešenie by mali byť opísané v skôr uvádzaných dokumentoch, pozri kapitolou

270 17.2 Bezpečnosť IS vo fáze analýzy IS Z hľadiska zaistenia bezpečnosti IS v tejto fáze životného cyklu by mali prebiehať nasledovné procesy: c) Analýza a manažment rizík IS, d) Analýza stavu implementácie bezpečnostných opatrení v praxi Analýza a manažment rizík IS Bezpečnostný manažér IS zabezpečí realizáciu analýzy rizík a návrh bezpečnostného skeletu IS pre schválený variant budovania nového IS alebo schválený variant rozvoja už prevádzkovaného IS. Výsledkom analýzy a manažmentu rizík IS, okrem iného, bude aj nasledovná bezpečnostná dokumentácia IS: Manažérska správa o výsledkoch identifikácie a ohodnotenia aktív IS, Manažérska správa o výsledkoch identifikácie a ohodnotenia hrozieb a zraniteľnosti, ako aj zistených rizikách IS, Manažérska správa o navrhovanom bezpečnostnom skelete IS. V rámci návrhu bezpečnostného skeletu IS je potrebné doriešiť aj možnosti uspokojenia bezpečnostných požiadaviek na IS špecifikované v štúdii IS, týkajúce sa schváleného variantu IS. Inou alternatívou je, že podnik nechá vykonanie AR na dodávateľa IS a len schváli jej výsledky. Aj za týchto okolností je nutná veľmi aktívna účasť podniku, pretože zber údajov pre AR prebieha najmä v podnikovom prostredí Analýza stavu implementácie bezpečnostných opatrení v praxi V prípade, keď ide o ďalší rozvoj už existujúceho IS, je potrebné analyzovať stav implementácie bezpečnostných opatrení daného IS v praxi. Sleduje sa tým cieľ zabrániť opakovanému riešeniu bezpečnostných problémov IS, ktoré už boli v minulosti nejako vyriešené. Samozrejme, už realizované bezpečnostné opatrenia je potrebné preveriť z hľadiska ich dostatočnosti za zmenených podmienok prevádzkovania IS a v odôvodnených prípadoch ich nahradiť inými vhodnejšími opatreniami. Výsledkom oboch opisovaných činností, okrem skôr spomínanej bezpečnostnej dokumentácie, súvisiacich s riešením bezpečnosti IS v tejto fáze životného cyklu IS bude vlastne: 270

271 c) Bezpečnostný skelet nového IS alebo d) Program zvýšenia bezpečnosti inovovaného IS, ktorý bude sadou bezpečnostných opatrení, ktoré sa majú doimplementovať pre daný IS v rámci zaistenia jeho bezpečnosti v zmenených podmienkach. Je vhodné ak takúto previerku vykonáva dodávateľ IS Bezpečnostné testy zahrnuté do akceptačného testovania IS V súvislosti s plánovaním akceptačného testovania IS platí, že bezpečnostný manažér IS (teda zástupca podniku) musí navrhnúť bezpečnostné testy, ktoré budú realizované ako súčasť akceptačného testovania. Dokumentácia bezpečnostných testov sa vypracováva s využitím toho istého inštrumentária ako ostatné testy, najmä funkčné a spoľahlivostné testy. Zhrnutie: Z predchádzajúceho textu tejto kapitoly vyplýva, že bezpečnostný manažér IS nevstupuje do Analytického projektu IS, ale vytvára vlastnú bezpečnostnú dokumentáciu IS, ktorá je však súčasťou celkovej dokumentácie projektu zameraného na vybudovanie nového IS. V súvislosti s riešením bezpečnosti IS sa vo fáze Analýza IS zabezpečujú 2 ďalšie etapy a vytvárajú 3 až 4 nové dokumenty, súvisiace s bezpečnosťou IS. 271

272 17.3 Bezpečnosť IS vo fáze projektovania Z hľadiska zaistenia bezpečnosti IS nasledovné procesy: v tejto fáze životného cyklu, by mali prebiehať c) Vypracovanie bezpečnostnej dokumentácie IS, d) Vypracovanie plánu bezpečnostných testov realizovaných v rámci integračného testovania Vypracovanie bezpečnostnej dokumentácie IS V závislosti od druhu IS, ktorý je projektovaný, bezpečnostný manažér IS zaistí vypracovanie najmä tejto bezpečnostnej dokumentácie: Bezpečnostná politika IS, Bezpečnostný zámer IS, Bezpečnostný projekt IS, Bezpečnostné smernice IS, Havarijný plán a plán obnovy činnosti IS. Je veľmi pravdepodobné, že prvé verzie dokumentov, najmä bezpečnostných smerníc a havarijného plánu, ako aj plánu obnovy činnosti IS budú spresňované tesne pred začatím rutinnej prevádzky IS Vypracovanie plánu bezpečnostných testov realizovaných v rámci integračného testovania Integrácia modulov IS zaisťuje nielen funkčnosť IS ako celku, ale aj prepojenie častí IS, vrátane s tým súvisiacich bezpečnostných procesov. Či už ide o ochranu odovzdávaných dát, zabezpečenie ich integrity a dôvernosti alebo vykonávanie nejakých procedúr zo strany používateľov IS, všetko je potrebné náležite otestovať. V súvislosti s plánovaním integračného testovania IS platí, že bezpečnostný manažér IS musí navrhnúť bezpečnostné testy, ktoré budú realizované ako súčasť integračného testovania. Dokumentácia bezpečnostných testov sa vypracováva s využitím toho istého inštrumentária ako ostatné testy, najmä funkčné a spoľahlivostné testy. Zhrnutie: Z predchádzajúce textu tejto kapitoly súčasne vyplýva, že bezpečnostný manažér IS nevstupuje do dokumentácie vypracovávanej inými špecialistami, ale vypracováva vlastnú bezpečnostnú dokumentáciu. V súvislosti s riešením bezpečnosti IS sa vo fáze Projektovanie IS zabezpečujú 2 ďalšie etapy a vytvára sa 6 nových dokumentov, súvisiacich s bezpečnosťou IS. 272

273 17.4 Bezpečnosť IS vo fáze vývoja softvéru IS Z hľadiska zaistenia bezpečnosti IS nasledovné procesy: v tejto fáze životného cyklu, by mali prebiehať c) Dohľad nad implementáciou bezpečnostných opatrení v aplikačnom softvéri, d) Vypracovanie bezpečnostných príručiek Dohľad nad implementáciou bezpečnostných opatrení v aplikačnom softvéri Súčasťou bezpečnostného skeletu IS sú aj bezpečnostné opatrenia, ktoré musia byť zabudované do samotnej aplikačnej časti IS, teda do softvéru. Ide najmä o opatrenia týkajúce sa: validácie vstupných dát, riadenia interného spracovania, autentizácie výstupných správ, validácie výstupných dát, uplatnenia kryptografických opatrení. Bezpečnostný manažér IS vykonáva dohľad nad implementovaním týchto opatrení do vytváraných softvérových modulov Vypracovanie bezpečnostných príručiek V závislosti od povahy IS a dát, ktoré budú IS spracúvané môže vzniknúť potreba vypracovať bezpečnostných príručiek pre niektoré skupiny používateľov a/alebo administrátorov či správcov. Ich vypracovanie zvyčajne zabezpečuje bezpečnostný manažér IS. Poznámka: Slovo zabezpečuje neznamená, že BMIS ich musí sám vypracovať, musí len zabezpečiť ich vypracovanie. Ich tvorcom môže byť napr. externá expertná firma pôsobiaca v oblasti informačnej bezpečnosti. Zhrnutie: V súvislosti s riešením bezpečnosti IS sa vo fáze Vývoj softvéru IS zabezpečujú 2 ďalšie etapy a vytvára sa 1 nový druh dokumentov, súvisiaci s bezpečnosťou IS. 273

274 17.5 Bezpečnosť IS vo fáze budovania HW a SW platformy Z hľadiska zaistenia bezpečnosti IS nasledovné procesy: v tejto fáze životného cyklu by mali prebiehať a) Dohľad nad dodávkou HW a SW; b) Dohľad nad inštalovaním HW a SW; c) Dohľad nad nastavovaním bezpečnostných parametrov OS, DB, aplikácií, sieťového prostredia; d) Dohľad nad vytváraním prvotných používateľov a ich prístupových práv; e) Dohľad nad fyzickou a objektovou bezpečnosťou Dohľad nad dodávkou HW a SW Vecnou podstatou dohľadu nad dodávkou HW a základného SW je zaistenie toho, aby nakupovaný HW a SW: mal požadované bezpečnostné vlastnosti, bol kompatibilný s už existujúcou platformou IS a nemal negatívny vplyv na existujúcu bezpečnosť IS prevádzkovaných podnikom Dohľad nad inštalovaním HW a SW Vecnou podstatou dohľadu nad inštalovaním HW a SW je zaistiť, aby bol inštalovaný HW a SW s dohodnutou konfiguráciou, resp. aby vytváraná alebo dobudovávaná platforma IS mala predpísanú konfiguráciu Dohľad nad nastavovaním bezpečnostných parametrov OS, DB, aplikácií, sieťového prostredia Dohľad nad nastavovaním bezpečnostných parametrov OS, DB, aplikácií, sieťového prostredia je jedným z kľúčových procesov, ktoré môžu mať priamy dopad na budúcu prevádzkovú bezpečnosť IS. BMIS by mal byť prítomný pri nastavovaní bezpečnostných parametrov kľúčových komponentov IS, mal by protokolárne schvaľovať realizované nastavenia Dohľad nad vytváraním používateľov a ich prístupových práv Dohľad nad vytváraním používateľov a ich prístupových práv je ďalším z kľúčových procesov, ktoré môžu mať priamy dopad na budúcu prevádzkovú bezpečnosť IS. 274

275 BMIS by mal byť prítomný pri vytváraní kľúčových rolí existujúcich v tíme prevádzkujúcom IS a nastavovaní ich oprávnení, ako aj pri vytváraní a nastavovaní tzv. prvotných používateľov. Súhlas BMIS by mal byť dokladovaný podpisom príslušných protokolov Dohľad nad fyzickou a objektovou bezpečnosťou Opatrenia pre fyzickú a objektovú bezpečnosť a chránia IS pred viacerými vážnymi hrozbami. sú súčasťou bezpečnostného skeletu IS Preto preverenie toho, že plánované bezpečnostné opatrenia boli realizované a fungujú správne, je vážnou povinnosťou bezpečnostného manažéra IS. Na druhej strane bezpečnostný manažér IS tieto opatrenia sám nerealizuje ale len dohliada na ich realizáciu alebo preveruje ich skutočný stav. Preto sa BMIS zúčastňuje minimálne procesu preberania už zrealizovaných bezpečnostných opatrení súvisiacich s fyzickou a objektovou bezpečnosťou. Zhrnutie: V rámci fázy Budovanie HW a SW platformy IS sa v súvislosti s bezpečnosťou IS vykonáva 5 nových činností. BMIS nevytvára nové dokumenty, jeho prítomnosť a prípadne súhlas, či nesúhlas by mali byť zdokumentované v rôznych protokoloch vytváraných počas realizácie jednotlivých etáp zahrnutých to tejto fázy. 275

276 17.6 Bezpečnosť IS vo fáze integrácie a testovania IS Z hľadiska zaistenia bezpečnosti IS nasledovné procesy: v tejto fáze životného cyklu by mali prebiehať c) Realizácia bezpečnostných testov zahrnutých do integračného testovania, d) Dohľad nad konfiguráciou systému Realizácia bezpečnostných testov zahrnutých do integračného testovania V tejto fáze životného cyklu sa musia uskutočniť, vyhodnotiť a prípadne prijať korekčné opatrenia vyplývajúce z výsledkov bezpečnostných testov zahrnutých do integračného testovania Dohľad nad konfiguráciou systému Pod konfiguráciou systému sa rozumie zoznam a opis jednotlivých modulov a ich verzií, z ktorých sa skladá aktuálny IS. Ďalej sú tu opísané procedúry vykonané pre zostavenie aktuálnej konfigurácie systému a počiatoční používatelia s ich prístupovými právami. Bezpečnostný manažér IS vykonáva dohľad nad spresnením konfigurácie systému na základe výsledkov integračného testovania a ich výsledkov. Konfigurácia systému uzatvorená po skončení integračných testov je tou, ktorá je zhotoviteľom IS určená pre budúcu rutinnú prevádzku IS. Zhrnutie: V rámci fázy Integrácia a testovanie IS sa v súvislosti s bezpečnosťou IS vykonávajú 2 nové činnosti. BMIS nevyhnutne nevytvára nové dokumenty, jeho prítomnosť a prípadne súhlas, či nesúhlas by mali byť zdokumentované v rôznych protokoloch vytváraných počas realizácie jednotlivých etáp zahrnutých to tejto fázy. 276

277 17.7 Bezpečnosť IS vo fáze akceptačného testovania Z hľadiska zaistenia bezpečnosti IS nasledovné procesy: by v tejto fáze životného cyklu mali prebiehať d) Realizácia bezpečnostných testov zahrnutých do akceptačného testovania, e) Dohľad nad zaškolením používateľov, f) Dohľad nad protokolárnym prevzatím IS do rutinnej prevádzky Realizácia bezpečnostných testov zahrnutých do akceptačného testovania V tejto fáze životného cyklu IS je potrebné realizovať a vyhodnotiť bezpečnostné testy pripravené pre akceptačné testovanie v predchádzajúcich fázach. Na základe výsledkov akceptačných testov je podľa potreby potrebné prijať korekčné opatrenia, ktoré zaistia odstránenie zistených nedostatkov. Realizáciu bezpečnostných testov, zahrnutých do akceptačného testovania zo strany budúceho prevádzkovateľa, zabezpečuje bezpečnostný manažér IS Dohľad nad zaškolením používateľov Predpokladom bezproblémového, ale aj bezpečného prevádzkovania IS je dobrá príprava budúcich používateľov na prácu so systémom. Súčasťou zaškolenia nie je len zvládnutie nových funkčností, ale aj nácvik bezpečnostných procedúr. Dohľad nad zaškoľovaním používateľov zo strany budúceho prevádzkovateľa zabezpečuje bezpečnostný manažér IS. BMIS môže sám alebo pracovníci jeho útvaru môžu školenia. realizovať vybrané bezpečnostné Dohľad nad protokolárnym prevzatím IS do rutinnej prevádzky Práve existujúca zostava IS preberaná do rutinnej prevádzky od zhotoviteľa je tým prvkom, ktorý určuje základ budúcej prevádzkovej bezpečnosti IS. Dôkladné zdokumentovanie bezpečnostného manažmentu IS. preberaného IS je preto veľmi významným prvkom Protokol o preberaní IS by mal byť verným obrazom toho, čo sa od zhotoviteľa reálne preberá. 277

278 Dohľad zo strany budúceho prevádzkovateľa z hľadiska bezpečnostný manažér IS podniku. bezpečnosti IS zabezpečuje 17.8 Bezpečnosť IS vo fáze prevádzky a údržby Z hľadiska zaistenia bezpečnosti IS nasledovné procesy: v tejto fáze životného cyklu by mali prebiehať a) Manažment konfigurácií a zmien, b) Kapacitný manažment, c) Udržiavanie prevádzkovej dokumentácie, d) Údržba, e) Monitorovanie bezpečnostne relevantných zmien, f) Auditné záznamy a protokolovanie, g) Bezpečnostné testovanie, h) Riadenie médií, i) Oddelenie povinností, j) Správne používanie softvéru, k) Riadenie zmien softvéru, l) Archivácia a zálohovanie dát, m) Ošetrovanie bezpečnostných incidentov, n) Interný audit bezpečnosti, o) Externý audit bezpečnosti, p) Bezpečnosť pri likvidácii IS Manažment konfigurácií a zmien Konfiguračný manažment je proces sledovania zmien v zložení a nastavení komponentov IS. Jeho primárnym bezpečnostným cieľom je zaistiť, aby zmeny v IS neznižovali efektivitu bezpečnostných opatrení a celkovej poskytovanej bezpečnosti. Manažment zmien môže prispieť k identifikácii nových bezpečnostných potrieb po tom, čo došlo k zmenám na IS Kapacitný manažment Kapacitný manažment by sa mal používať na predchádzanie zlyhaniam z dôvodu neadekvátnej prevádzkovej kapacity systému. Pri určovaní kapacity potrebnej pre určitý IS, by sa mali brať do úvahy budúce kapacitné požiadavky a aktuálne vývojové trendy. Dohľad nad kapacitným manažmentom vykonáva bezpečnostný manažér IS. 278

279 Prevádzková dokumentácia Všetky aspekty konfigurácií a prevádzky IS by mali byť dokumentované, s cieľom zaistiť kontinuitu a súlad. Bezpečnosť systému IS je tiež potrebné zdokumentovať v bezpečnostnej politike IS, bezpečnostnom projekte, dokumentoch procedúr bezpečnej prevádzky, v zostavách a plánoch zachovania nepretržitosti činnosti, ako aj plánoch obnovy činnosti spoločnosti po havárii. Dokumentácia by mala byť aktuálna a prístupná zamestnancom, ktorí ju majú používať. Dohľad nad prevádzkovou dokumentáciou a udržiavanie bezpečnostnej dokumentácie IS vykonáva bezpečnostný manažér IS Údržba Prostriedky IT by mali byť správne udržiavané, aby sa zaistila ich neustála spoľahlivosť, dostupnosť a integrita. Všetky bezpečnostné požiadavky, ktoré musia byť splnené poskytovateľmi údržby, by mali byť plne dokumentované v zmluvách o údržbe. Údržba by sa mala realizovať v súlade s dodávateľskými zmluvami a mala by byť vykonávaná len autorizovaným personálom. Dohľad nad údržbou vykonáva bezpečnostný manažér IS v spolupráci s administrátormi komponentov IS Monitorovanie bezpečnostne relevantných zmien Zmeny na dopadoch, hrozbách, zraniteľnostiach a rizikách a s nimi spojených charakteristikách by mali byť monitorované. Monitorovanie by malo obsahovať existujúce a aj nové aspekty bezpečnosti. Prostredie, v ktorom sa systém nachádza, by malo byť tiež monitorované. Monitorovanie bezpečnostne relevantných zmien zaisťuje bezpečnostný manažér IS Auditné záznamy a protokolovanie Mali by sa využívať auditné a protokolovacie schopnosti serverov (napríklad schopnosti zaznamenávania do auditného záznamu a analyzovania), sietí (napríklad schopnosti auditovania firewallov a routerov) a aplikácií (napríklad schopnosti auditovania aplikácií spracovávajúcich správy alebo transakcie) na zaznamenávanie detailov bezpečnostne relevantných udalostí. 279

280 Toto zahŕňa podrobnosti o ľahko identifikovateľných neautorizovaných alebo chybových udalostiach a detaily o zjavne normálnych udalostiach, ktoré môže byť potrebné neskôr analyzovať. Auditné záznamy a protokoly by mali byť pravidelne prezerané, kvôli detekcii neautorizovaných aktivít a umožneniu vykonania vhodných nápravných opatrení. Udalosti v protokoloch by mali byť analyzované aj z hľadiska opakovania podobných udalostí, ktoré môžu indikovať prítomnosť zraniteľností alebo hrozieb, pre ktoré existujú neprimerané opatrenia. Takáto analýza môže odhaliť aj vzorky v zjavne nesúvisiacich udalostiach, ktoré môžu umožniť identifikáciu ľudí, vykonávajúcich neautorizované aktivity alebo hlavnú príčinu bezpečnostného problému. Pravidelné prezeranie auditných záznamov zabezpečujú vybraní správcovia a bezpečnostný manažér IS Bezpečnostné testovanie Bezpečnostné testovanie by sa malo používať s cieľom zaistiť, aby všetky súvisiace softvérové komponenty pracovali bezpečným spôsobom. Bezpečnostné testovanie by malo zahŕňať bezpečnostné požiadavky definované v bezpečnostnej politike IS a v testovacích plánoch a mali by sa stanoviť akceptačné kritériá, s cieľom preukázať že je dosiahnutá požadovaná úroveň bezpečnosti. Bezpečnostné testovanie IS počas rutinnej prevádzky zaisťuje bezpečnostný manažér IS. Je vhodné, ak okrem interného bezpečnostného testovania prebieha aj externé penetračné testovanie odolnosti IS voči známym útokom hackerov Riadenie médií Riadenie médií zahŕňa škálu opatrení na poskytnutie fyzickej a environmentálnej ochrany a zodpovednosti za pásky, disky, výpisy alebo iné médiá. Toto zahŕňa označovanie, protokolovanie, verifikáciu integrity, ochranu fyzického prístupu, ochranu prostredia, prenos a bezpečnú likvidáciu. Dohľad nad riadením médií zaisťuje bezpečnostný manažér IS Oddelenie povinností Aby sa minimalizovali riziká a možnosti zneužitia privilégií, tam kde je to potrebné a možné, malo by sa aplikovať oddelenie povinností. 280

281 Najmä by mali byť oddelené povinnosti a funkcie, ktoré v kombinácii môžu viesť k obídeniu bezpečnostných opatrení alebo auditov alebo k nepatričným výhodám niektorého zamestnanca. Prideľovanie rolí, vrátane uplatňovania separácie a bezpečnostný manažér IS. schvaľovanie privilégií, zaisťuje Správne používanie softvéru Malo by sa zaistiť, aby sa nekopíroval žiadny materiál chránený autorským právom a aby boli dodržiavané licenčné zmluvy k autorizovanému softvéru. Dohľad nad dodržiavaním licenčných a autorských práv zaisťuje bezpečnostný manažér IS Riadenie zmien softvéru IS a prostredie, v ktorom pracujú, sa stále mení. Tieto zmeny sú výsledkom dostupnosti nových funkcií a služieb alebo objavenia sa nových hrozieb a zraniteľností. Tieto zmeny môžu taktiež vyústiť do nových hrozieb a zraniteľností. Zmeny IS zahŕňajú: nové procedúry, nové funkcie, softvérové aktualizácie, hardvérové revízie, nových používateľov zahŕňajúcich externé skupiny alebo anonymné skupiny, dodatočné tvorenie siete a pripojenie. Keď nastane alebo je plánovaná zmena IS, je dôležité určiť aký dopad bude mať na bezpečnosť systému. Ak má systém Výbor riadenia konfigurácie alebo inú organizačnú štruktúru na riadenie technických systémových zmien, mal by byť do nej zaradený bezpečnostný manažér IS alebo jeho zástupca a mala by mu byť pridelená zodpovednosť ohľadne posudzovania, či zmeny ovplyvnia bezpečnosť a ak áno, ako. Pri veľkých zmenách, ktoré zahŕňajú zakúpenie nového hardvéru, softvéru alebo služieb, bude na určenie nových bezpečnostných požiadaviek potrebná analýza. Na druhej strane mnohé zmeny na systémoch sú malé, čo do povahy a nevyžadujú rozsiahlu analýzu, aká je potrebná pre veľké zmeny, avšak určitú analýzu vyžadujú. Pre oba typy zmien by mala byť vykonaná analýza berúca do úvahy prínosy a náklady. Pri malých zmenách môže byť analýza vykonaná neformálne na schôdzach, ale výsledok a rozhodnutia riadiacich pracovníkov by mali byť dokumentované. 281

282 Malo by sa aplikovať riadenie zmien softvéru, s cieľom udržiavať pri vykonávaní zmien integritu softvéru. Mali by byť zriadené procedúry riadenia zmien pre softvér, ktoré kontrolujú všetky zmeny a zaisťujú, aby bola počas celého procesu udržiavaná bezpečnosť. Toto zahŕňa autorizáciu zmien, bezpečnostné posudzovanie dočasných riešení a bezpečnostné previerky konečných riešení Archivácia a zálohovanie dát Pre každý informačný systém využívaný spoločnosťou musí byť určená stratégia zálohovania a archivácie dát. Aktuálne zálohy a archivované dáta sú významným prvkov zvládania nefunkčností a havárií IS. Dohľad nad zálohovaním a archiváciou dát zaisťuje bezpečnostný manažér IS Ošetrovanie bezpečnostných incidentov Každá spoločnosť by sa mala plánovito pripraviť na incidenty existujúcou efektívnou schémou analyzovania incidentov, zahŕňajúcou: prípravu vopred dokumentované preventívne opatrenia, smernice a procedúry na ošetrovanie incidentov (vrátane ochrany dôkazov, údržby záznamov udalostí a riešenia vzťahov s verejnosťou), potrebnej dokumentácie a plánov nepretržitosti činnosti spoločnosti; oznamovanie - procedúry, prostriedky a zodpovednosti oznamovania incidentov, vrátane toho komu sa má oznamovať; ohodnocovanie - procedúry a zodpovednosti za prešetrovanie incidentov a určovanie ich vážnosti; riadenie - procedúry a zodpovednosti za riešenie incidentov, obmedzovanie z nich plynúcich škôd, likvidáciu incidentov a oboznámenie vyššieho manažmentu; obnovu - procedúry a zodpovednosti za opätovné zriadenie normálnej prevádzky; posúdenie - procedúry a zodpovednosti za post-incidentové činnosti, vrátane prešetrenia právnych následkov a analýzy trendov. Zatiaľ čo používanie štandardnej schémy analyzovania incidentov prináša jednotlivým spoločnostiam úžitok, je potrebné zvážiť, či ešte väčší úžitok nemôže vyplynúť zo zdieľania určitých informácií o incidentoch s inými spoločnosťami, s cieľom rozšíriť základňu pre získanie "alarmov", rýchle identifikovanie trendov a umožnenie prevencie. Aby sa umožnilo spoločné využitie poznatkov viacerými spoločnosťami, mala by sa používať taká štruktúra schémy analýzy incidentu, ktorá je dostatočne flexibilná, aby mohla pokryť škálu všetkých (všetky sektory, typy hrozieb a dopady) potrieb založených na sektore / hrozbe / dopade. 282

283 Bez ohľadu na to, či ide o problém do vnútra spoločnosti alebo jeho využitie je za hranicami spoločnosti, každá schéma analyzovania incidentov musí používať podobnú typológiu, metriku a štruktúru na záznam informácií o incidentoch. Toto umožní porovnávanie a analýzu. Informácie o výskyte hrozieb výrazne napomôžu kvalite ohodnotenia hrozieb, a teda aj ohodnotenia rizík. Okrem toho, počas vyšetrovania určitého incidentu alebo incidentov je pravdepodobné, že budú zhromaždené nové a dodatočné informácie ohľadom zraniteľností a spôsobu ako môžu byť využité. Využitie schémy analyzovania incidentov umožňuje používateľovi identifikovať a zhodnotiť zraniteľnosti, a teda poskytnúť hodnotné vstupné informácie pre metódy analýzy rizík. Toto bude čiastočne založené na informáciách vložených s ohľadom na hrozby a čiastočne s ohľadom na výsledky prešetrovania incidentov, napríklad tímami odozvy na počítačové nebezpečenstvo. Napríklad hrozba logickej infiltrácie (prítomnosť útočníka a atraktivita spracúvaných informácií) sa môže skombinovať so zraniteľnosťou voči logickej infiltrácii (neadekvátnosť alebo absencia primeraných mechanizmov riadenia logického prístupu) a tak vytvoriť riziko. Informácie o podozrivých udalostiach a bezpečnostných incidentoch preberá a ich ošetrovanie riadi bezpečnostný manažér IS Interný audit bezpečnosti IS Interný audit bezpečnosti IS je jednou zo zásad dobrej praxe pre bezpečnosti. riadenie informačnej Interné bezpečnostné audity odhaľujú prípadné bezpečnostné problémy existujúce pri prevádzke IS ešte pred tým, než ich nájde nezávislý externý audítor. Poznatky získané internými auditmi sa využívajú na prípravu korekčných a preventívnych opatrení zaisťujúcich, že bezpečnosť IS bude stále na požadovanej úrovni. Interný audit bezpečnosti IS plánuje a vykonáva interných auditoch potrebnú súčinnosť. interný audítor. BMIS poskytuje pri Vzťah interného audítora a BMIS má povahu vzájomnej kontroly. BMIS potrebuje aby interní audítor vykonával dobre pripravené interné audity a kontroluje, či sa plní plán interných auditov. Na druhej strane interný audítor má vo svojich plánoch zaradené aj previerky činnosti BMIS, pretože pre podnik je dôležité aby BMIS v plnom rozsahu napĺňal svoje poslanie Externý audit bezpečnosti IS Pre väčšinu prevádzkovaných IS je niektorou zložkou platnej legislatívy určená povinnosť vykonávať pravidelný nezávislý externý bezpečnostný audit. Týka sa to bánk, finančných inštitúcií, poisťovní, ako aj iných typov organizácii. 283

284 Požadovaná frekvencia sa pohybuje od raz ročne vykonávaného externého auditu po jeden audit vykonávaný za 2 až 3 roky. Platná legislatíva vo viacerých prípadoch predpisuje auditované oblasti, formu výstupu z auditu, prípadne metodické zázemie pre vykonanie auditu. Externý audit bezpečnosti IS zaisťuje nezávislý externý audítor. BMIS a interný audítor podniku poskytuje počas externého auditu potrebnú súčinnosť Bezpečnosť pri likvidácii IS Pri ukončovaní životného cyklu IS je tiež potrebné pamätať na bezpečnosť. V žiadnom prípade nie je jedno, komu budú sprístupnené informácie z likvidovaného IS, kto bude mať k dispozícií jeho prevádzkovú a bezpečnostnú dokumentáciu, ako sa z prevádzkového priestoru stiahnu neplatné kópie softvéru, výstupné zostavy či manuály. Likvidácii IS by mal predchádzať likvidačný plán, ktorého súčasťou je aj súbor primeraných bezpečnostných opatrení. Bezpečnostné pravidlá platné pre likvidáciu IS a dohľad nad ich dodržiavaním spadá do kompetencií bezpečnostného manažéra IS. Zhrnutie: Počas fázy Prevádzka a údržba IS sa zabezpečuje viac ako 15 nových druhov činností súvisiacich s bezpečnosťou IS. Počet typov záznamov, protokolov a správ súvisiacich s bezpečnosťou IS, vznikajúcich v tejto fáze životného cyklu IS, je ešte väčší. 284

285 17.9 Výstupné dokumenty z riadenia bezpečnosti IS vo fázach životného cyklu IS Rekapitulácia výstupných dokumentov z riadenia bezpečnosti IS vo fázach životného cyklu IS usporiadaná podľa fáz je nasledovná: Poznámka: V nasledujúcej tabuľke sa vyskytujú 2 funkcie súvisiace s riešením bezpečnosti IS, a to: Projektant bezpečnosti IS Manažér bezpečnosti IS. Uvedené súvisí s tým, že je žiaduce, aby dodávateľ nového IS mal vo svojom tíme člena, ktorý sa stará o bezpečnosť vytváraného IS a ním zastávaná funkcia sa často nazýva BMIS, zriedkavejšie projektant bezpečnosti IS. Súčasne budúci prevádzkovateľ IS má tiež vo svojom tíme člena, ktorý sa stará o bezpečnosť IS a ním zastávaná funkcia sa v praxi tiež nazýva BMIS. Pre odlíšenie zodpovednosti za realizáciu činností súvisiacich s riešením bezpečnosti IS sa preto v rámci týchto skrípt: o o na strane zhotoviteľa IS používa označenie projektant bezpečnosti IS a na strane prevádzkovateľa IS sa používa označenie bezpečnostný manažér IS - BMIS. 285

286 Fáza životného cyklu Výstupné dokumenty z riadenia bezpečnosti IS P.č. Názov fázy Činnosť Zaisťuje Výstupné dokumenty 1. Plánovanie a riadenie Špecifikácia zámeru z hľadiska bezpečnosti IS Špecifikácia možných variantov riešenia bezpečnosti IS Plán procesov pre riešenie bezpečnosti IS Predkladateľ IS Predkladateľ štúdie IS Projektant bezpečnosti IS Inovačný zámer Štúdia IS Plán budovania IS 2. Analýza IS Analýza a manažment rizík IS Projektant bezpečnosti IS v spolupráci s Bezpečnostným manažérom IS Manažérska správa o výsledkoch identifikácie a ohodnotenia aktív IS Manažérska správa o výsledkoch identifikácie a ohodnotenia hrozieb a zraniteľnosti, ako aj zistených rizikách IS Manažérska správa o navrhovanom bezpečnostnom skelete IS Analýza stavu implementácie bezpečnostných opatrení v praxi Príprava plánu bezpečnostných testov pre akceptačné testovanie IS Projektant bezpečnosti IS v spolupráci s Bezpečnostným manažérom IS Projektant bezpečnosti IS v spolupráci s Bezpečnostným manažérom IS Správa o stave implementácie bezpečnostných opatrení Program zvýšenie bezpečnosti IS Plán akceptačného testovania IS 286

287 Fáza životného cyklu Výstupné dokumenty z riadenia bezpečnosti IS P.č. Názov fázy Činnosť Zaisťuje Výstupné dokumenty 3. Fáza projektovania Vypracovanie bezpečnostnej dokumentácie IS Projektant Bezpečnostná politika IS bezpečnosti IS Bezpečnostný zámer IS v spolupráci s Bezpečnostný projekt IS Bezpečnostným Bezpečnostné smernice IS manažérom IS Havarijný plán a plán obnovy činnosti IS Vypracovanie plánu bezpečnostných testov realizovaných v rámci integračného testovania Projektant bezpečnosti IS Plán integračných testov 4. Fáza vývoja softvéru Dohľad nad implementáciou bezpečnostných opatrení v aplikačnom softvéri Vypracovanie bezpečnostných príručiek Projektant bezpečnosti IS v spolupráci s Bezpečnostným manažérom IS Projektant bezpečnosti IS Záznamy z previerok implementácie bezpečnostných opatrení v aplikačnom softvéri Bezpečnostné príručky 287

288 Fáza životného cyklu Výstupné dokumenty z riadenia bezpečnosti IS P.č. Názov fázy Činnosť Zaisťuje Výstupné dokumenty 5. Fáza budovania HW a SW platformy Dohľad nad dodávkou HW a SW 6. Fáza integrácie a testovania Dohľad nad inštalovaním HW a SW Dohľad nad nastavovaním bezpečnostných parametrov OS, DB, aplikácií, sieťového prostredia Dohľad nad vytváraním používateľov a ich prístupových práv Dohľad nad fyzickou a objektovou bezpečnosťou Realizácia bezpečnostných testov zahrnutých do integračného testovania Projektant bezpečnosti IS Projektant bezpečnosti IS Projektant bezpečnosti IS Projektant bezpečnosti IS Projektant bezpečnosti IS Projektant bezpečnosti IS Stanoviská Záznamy Stanoviská Záznamy Stanoviská Záznamy Stanoviská Záznamy Stanoviská Záznamy Záznamy z testovania 7. Fáza akceptačného testovania Dohľad nad konfiguráciou systému Realizácia bezpečnostných testov zahrnutých do akceptačného testovania Projektant bezpečnosti IS Bezpečnostný manažér IS Záznamy ku konfigurácii IS Záznamy z testovania Dohľad nad zaškolením používateľov Dohľad nad protokolárnym prevzatím IS do rutinnej prevádzky Bezpečnostný manažér IS Bezpečnostný manažér IS Záznamy BM IS Protokol o prevzatí IS do rutinnej prevádzky 288

289 Fáza životného cyklu Výstupné dokumenty z riadenia bezpečnosti IS P.č. Názov fázy Činnosť Zaisťuje Výstupné dokumenty 8. Fáza prevádzky a údržby IS Manažment konfigurácií a zmien Kapacitný manažment Dohľad nad dokumentáciou Dohľad nad údržbou Monitorovanie bezpečnostne relevantných zmien Prehliadanie auditných záznamov a protokolov Dohľad nad riadením médií Oddeľovanie povinností Dohľad nad správnym používaním softvéru Dohľad nad riadením zmien softvéru Dohľad nad archiváciou a zálohovaním dát Ošetrovanie bezpečnostných incidentov BM IS BM IS BM IS BM IS BM IS BM IS BM IS BM IS BM IS BM IS BM IS BM IS Záznamy Návrh na zakúpenie HW Záznamy Aktualizovaná dokumentácia Záznamy Dokumentácia opakovanej analýzy rizík Záznamy a návrhy opatrení Záznamy Protokoly o pridelení rolí a určení privilégií Záznamy Záznamy a stanoviská Záznamy Záznamy, protokoly, návrhy opatrení Interný audit bezpečnosti Externý audit bezpečnosti Bezpečnosť pri likvidácii IS Interný audítor Externý audítor BM IS Plány auditov, správy o výsledkoch auditov, návrh opatrení Plány auditov, správy o výsledkoch auditov, návrh opatrení Bezpečnostné pravidlá pre likvidáciu IS 289

290 18 Budovanie ISMS - Systému riadenia informačnej bezpečnosti Požiadavky na ISMS definuje medzinárodná norma ISO/IEC 27001:2005. Táto medzinárodná norma bola pripravená s cieľom poskytnúť model na zostavenie (návrh), implementáciu, prevádzku, monitorovanie, preskúmavanie a zlepšovanie Systému riadenia informačnej bezpečnosti (Information Security Management System (ISMS)). Koncepcia a implementácia ISMS organizácie sú ovplyvnené podnikovými potrebami a cieľmi, bezpečnostnými požiadavkami, používanými procesmi a veľkosťou a štruktúrou organizácie. Predpokladá sa, že tieto faktory a ich podporné systémy sa časom menia. Očakáva sa, že implementácia ISMS musí byť vykonaná v rozsahu, ktorý je v súlade s potrebami organizácie, napr. jednoduchá situácia si vyžaduje jednoduché riešenie ISMS. Norma konštatuje, že: ISMS - Systém riadenia informačnej bezpečnosti je tá časť celkového systému riadenia, ktorá je založená na prístupe k riziku podniku, ktorej úlohou je zaviesť, implementovať, prevádzkovať, monitorovať, revidovať, udržiavať a zlepšovať informačnú bezpečnosť. ISMS by mal byť pritom skonštruovaný tak, aby zabezpečoval postačujúce a úmerné bezpečnostné opatrenia, ktoré dostatočne chránia informačné aktíva a poskytujú dôveru zákazníkom a iným zainteresovaným stranám. Toto možno premietnuť do udržiavania a zlepšovania konkurenčných výhod, cash-flow, ziskovosti, súladu so zákonnými požiadavkami a obchodným imidžom. Budovanie ISMS musí byť strategickým rozhodnutím vedenia podniku/organizácie/spoločnosti. 290

291 18.1 Vzťah medzi ISMS a bezpečnosťou IS Pre potrebu týchto skrípt postačuje nasledujúce stručné vysvetlenie vychádzajúce z uvádzaného obrázku. Vzťah medzi bezpečnosťou informačných systémov a systémom riadenia informačnej bezpečnosti je znázornený obrázkom č Obrázok č Vzťahy medzi ISMS a bezpečnosťou IS Z obrázku č.18-1 vyplýva, že: ISMS je akou si strechou existujúcou nad samotnými IS, pričom vecným obsahom je výkon prierezových činnosti vykonávaných z bezpečnostného hľadiska za celú organizáciu a teda aj pre jednotlivé IS Opatrenia realizované pre budovanie a prevádzku firemného ISMS prispievajú naplneniu cieľov pre požadovanú ochranu IS Opatrenia realizované pre ochranu IS prispievajú naplneniu cieľov určených pre firemný ISMS. 291