H Smjernice Za Upravljanje Informacijskim Sustavom

SMJERNICE ZA UPRAVLJANJE INFORMACIJSKIM SUSTAVOM U CILJU SMANJENJA OPERATIVNOG RIZIKA
OUJAK 2006.
Hrvatska narodna banka
Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika
Sadraj
1. Uvod .......................................................................................................................................4 1.1. Temeljna naela informacijskog sustava.........................................................................6 1.2. Ciljevi, strategije i ostali interni akti ...............................................................................7 1.3. Sigurnost informacijskog sustava....................................................................................8 1.4. Elementi upravljanja rizikom ..........................................................................................9 2. Upravljanje informacijskim sustavom..................................................................................13 2.1. Uprava banke.................................................................................................................16 2.2. Voditelj organizacijske jedinice za informacijsku tehnologiju .....................................17 2.3. Voditelj sigurnosti informacijskog sustava ...................................................................18 2.4. Odbor za upravljanje informacijskim sustavom............................................................19 2.5. Upravljanje projektima..................................................................................................21 3. Upravljanje rizikom informacijskog sustava........................................................................23 3.1. Procjena rizika...............................................................................................................24 3.2. Smanjivanje rizika.........................................................................................................30 3.3. Kontrole.........................................................................................................................33 3.4. Klasifikacija informacija ...............................................................................................35 4. Unutarnja revizija.................................................................................................................36 5. Sigurnost informacijskog sustava.........................................................................................38 5.1. Politika sigurnosti informacijskog sustava....................................................................39 5.2. Upravljanje kontrolama pristupa...................................................................................40 5.3. Kriptografija ..................................................................................................................47 5.4. Fizika sigurnost............................................................................................................48 5.5. Upravljanje operativnim i sistemskim zapisima............................................................49 5.6. Zatita od malicioznog koda..........................................................................................51 6. Odravanje informacijskog sustava......................................................................................53 6.1. Upravljanje imovinom informacijskog sustava.............................................................53 6.2. Upravljanje promjenama ...............................................................................................55 6.3. Upravljanje konfiguracijama.........................................................................................57 6.4. Dokumentacija...............................................................................................................58 6.5. Izobrazba .......................................................................................................................59 7. Planiranje kontinuiteta poslovanja .......................................................................................61 7.1. Analiza utjecaja na poslovanje......................................................................................63 7.2. Plan kontinuiteta poslovanja..........................................................................................65 7.3. Plan oporavka................................................................................................................66 7.4. Upravljanje incidentima ................................................................................................67 7.5. Upravljanje priuvnom pohranom.................................................................................70 8. Razvoj sustava i eksternalizacija..........................................................................................72 8.1. Razvoj informacijskih sustava unutar banke.................................................................72 8.2. Eksternalizacija (dijela) informacijskog sustava...........................................................76 9. E-bankarstvo.........................................................................................................................82 9.1. Uvod ..............................................................................................................................82 9.2. Rizici povezani s e-bankarstvom...................................................................................84 9.3. Upravljanje rizikom e-bankarstva .................................................................................85 10. Zakljuci i preporuke..........................................................................................................92
1. Uvod
Osnovna naela u poslovanju banaka jesu naelo likvidnosti i naelo solventnosti. Kako bi osigurale poslovanje u skladu sa spomenutim naelima, banke su dune kontinuirano obavljati mjerenje, procjenu i upravljanje svim rizicima kojima su u svom poslovanju izloene. Rizici kojima su banke izloene u svom poslovanju i za koje minimalno moraju biti propisani postupci mjerenja, procjene i upravljanja ukljuuju i rizik koji proizlazi iz neadekvatnog upravljanja informacijskim i pridruenim tehnologijama. Hrvatska narodna banka uoila je potrebu da se bankama radi osiguranja sigurnosti i stabilnosti bankarskog poslovanja u Republici Hrvatskoj skrene pozornost na pitanja vezana uz rizik koji proizlazi iz neadekvatnog upravljanja informacijskim i pridruenim tehnologijama. Banke u svom poslovanju ovise o koritenju informacija. Pravodobne, tone i potpune informacije, s obzirom na njihov utjecaj na poslovanje i odluivanje, kljune su za ostvarivanje poslovnih ciljeva. Informacijska tehnologija omoguuje koritenje i upravljanje informacijama odnosno podrava i unapreuje poslovne procese kako bi se to djelotvornije ostvarivali poslovni ciljevi i postigla konkurentska prednost. Meudjelovanje informacijske tehnologije, podataka i postupaka za procesiranje podataka te ljudi koji prikupljaju i koriste navedene podatke ini informacijski sustav. Drugim rijeima, informacijski je sustav sveobuhvatnost infrastrukture, organizacije, ljudi i postupaka za prikupljanje, obradu, generiranje, pohranu, prijenos, prikaz, distribuciju informacija i raspolaganje njima. S obzirom na ubrzani razvoj i sveprisutnost informacijske tehnologije u poslovnom okruenju, uporaba informacijskih sustava: jest jedan od kljunih imbenika u poslovanju banke; poveava meudjelovanje raznih sustava, jer se informacijski sustavi banke povezuju s klijentima, pruateljima usluga te ostalim subjektima preko javno dostupnih i privatnih telekomunikacijskih mrea; postavlja temelj za razvoj novih proizvoda i usluga te utjee na oblikovanje konkurentskih prednosti; pokree reinenjering strateki vanih poslovnih procesa; poveava potrebu za novim ulaganjima u resurse informacijskog sustava; zahtijeva usvajanje i primjenu novih strunih znanja. Iz navedenog proizlazi da je koritenje informacijske tehnologije u svim aspektima bankarskog poslovanja stvorilo veliku ovisnost o informacijskoj tehnologiji pa je prema tome potrebno posvetiti veliku pozornost upravljanju informacijskim sustavom kao sastavnom dijelu upravljanja bankom u cjelini. Nadalje, u sklopu upravljanja informacijskim sustavom posebnu pozornost potrebno je obratiti upravljanju rizikom koji proizlazi iz koritenja informacijskog sustava, kako bi se osiguralo pouzdano, sigurno i kontinuirano poslovanje banke. Rizici se procjenjuju s aspekta uinka koji bi mogao biti uzrokovan naruavanjem funkcionalnosti i sigurnosti informacijskog sustava, odnosno naruavanjem temeljnih naela informacijskog sustava (objanjava se u nastavku dokumenta). Upravljanje rizikom informacijskog sustava, za potrebe ovog dokumenta, obuhvaa postupke procjene rizika te poduzimanja radnja za smanjenje rizika na prihvatljivu razinu i odravanje prihvatljive razine
rizika. Poveani rizik informacijskog sustava proizlazi iz neprimjerenog koritenja i upravljanja resursima informacijskog sustava, te moe poveati financijski, strateki, operativni, reputacijski i pravni rizik.
1.1. Temeljna naela informacijskog sustava

Funkcionalan i siguran informacijski sustav mora se zasnivati na sljedeim temeljnim naelima: 1. povjerljivosti: svojstvu da informacije ne budu dostupne ili otkrivene neovlatenim subjektima; 2. integritetu: svojstvu da informacije i procesi nisu neovlateno ili nepredvieno mijenjani; 3. raspoloivosti: svojstvu koje omoguuje pristup i upotrebljivost na zahtjev ovlatenog subjekta; 4. neporecivosti: svojstvu koje osigurava nemogunost poricanja izvrene aktivnosti ili primitka informacije; 5. dokazivosti: svojstvu koje osigurava da aktivnosti subjekta mogu biti praene jedinstveno do samog subjekta; 6. autentinosti: svojstvu koje osigurava da je identitet subjekta zaista onaj za koji se tvrdi da jest; 7. pouzdanosti: svojstvu dosljednog, oekivanog ponaanja i rezultata. Neporecivost, dokazivost, autentinost i pouzdanost mogu se promatrati i kao kombinacija naela povjerljivosti, integriteta i raspoloivosti. Posljedice naruavanja temeljnih naela informacijskog sustava jesu: Gubitak integriteta. Integritet sustava i podataka odnosi se na potrebu da informacije budu zatiene od neovlatenih ili neispravnih izmjena. Neovlatene ili neispravne izmjene dovode do gubitka integriteta. Ako integritet sustava ili podataka nije ponovo uspostavljen, nastavak koritenja takvim sustavom ili podacima moe dovesti do netonosti, prijevara ili pogrenih odluka. Isto tako, povreda integriteta moe biti prvi korak u naruavanju raspoloivosti ili povjerljivosti sustava. Zbog tih razloga gubitak integriteta smanjuje povjerenje u informacijski sustav. Gubitak raspoloivosti. Neraspoloivost informacijskog sustava potrebnog za obavljanje zadatka moe negativno utjecati na ciljeve banke i kontinuitet poslovanja te onemoguiti odvijanje vitalnih poslovnih procesa. Gubitak funkcionalnosti sustava i operativne djelotvornosti (uinkovitosti) moe, primjerice, dovesti do naruavanja reputacije banke, rezultirati gubitkom produktivnog vremena te onemoguiti krajnjeg korisnika u izvravanju radnih zadataka. Gubitak povjerljivosti. Neovlateno, neoekivano ili nenamjerno otkrivanje ili objavljivanje podataka moe rezultirati gubitkom povjerljivosti sustava i podataka. Gubitak povjerljivosti moe dovesti do tekih povreda vaeih propisa te utjecati na gubitak povjerenja javnosti i naruavanje reputacije banke, a moe prouzroiti i pokretanje sudskog postupka protiv banke. Pojam "temeljna naela informacijskog sustava" u nastavku dokumenta, ovisno o kontekstu, podrazumijeva jedno naelo ili kombinaciju naela povjerljivosti, integriteta, raspoloivosti, neporecivosti, dokazivosti, autentinosti i pouzdanosti.
1.2. Ciljevi, strategije i ostali interni akti

Ciljevi, strategije i ostali interni akti banke trebaju biti definirani tako da budu temelj za djelotvorno upravljanje informacijskim sustavom te da podravaju poslovne procese i temeljna naela informacijskog sustava. Ciljevi odreuju to treba ostvariti, dok strategije odreuju kako ostvariti postavljene ciljeve. Ciljevi, strategije i ostali interni akti trebaju se razvijati hijerarhijski od upravljake prema operativnoj razini te trebaju: odraavati potrebe organizacijskih jedinica unutar banke uzeti u obzir organizacijska i druga ogranienja osigurati dosljednost na svim razinama. Strategije i ostale interne akte potrebno je odravati i aurirati u skladu s promjenama poslovnih ciljeva i rezultatima periodinih provjera (primjerice procjenama rizika, revizijama informacijskog sustava) te u skladu s promjenama u okruenju.
1.3. Sigurnost informacijskog sustava

Banke pri obavljanju svojih poslovnih aktivnosti uvelike ovise o obradi i upotrebi informacija. Naruavanje temeljnih naela informacijskog sustava moe imati negativne posljedice za banku. Stoga je potrebno primjereno zatititi informacije i upravljati sigurnou informacijskog sustava banke. Potreba za zatitom informacija i upravljanjem sigurnou posebice je vana u dananjem okruenju jer su informacijski sustavi banaka povezani s drugim informacijskim sustavima. Upravljanje sigurnou informacijskog sustava jest, izmeu ostalog, sveobuhvatan, detaljan i sustavan proces identificiranja potreba (radi ostvarivanja zadovoljavajue razine sigurnosti) te postizanja i odravanja zadovoljavajue razine sigurnosti informacijskog sustava.
1.4. Elementi upravljanja rizikom

1.4.1. Resursi informacijskog sustava Pravilno upravljanje resursima informacijskog sustava kljuno je za uspjeh banke i za njega su odgovorne sve upravljake razine. Resursi, uz ostalo, ukljuuju: 1. opipljivu imovinu (primjerice hardver, komunikacijsku opremu, graevine) 2. informacije/podatke (primjerice dokumente, podatke u bazama podataka) 3. softver 4. sposobnost proizvodnje nekog proizvoda ili pruanja neke usluge (engl. know-how) 5. osobe koje odravaju i koriste informacijski sustav 6. neopipljivu imovinu (primjerice zatitni znak, reputaciju). Banka bi trebala identificirati i klasificirati resurse prema njihovoj vanosti i vrijednosti te odrediti i implementirati potreban stupanj zatite tih resursa. Proces identificiranja resursa i utvrivanja njihove vanosti i vrijednosti moe biti obavljen na najvioj razini i ne mora ukljuivati skupe, detaljne i vremenski zahtjevne analize. Detaljnost analize utvruje se na temelju postavljenih funkcionalnih i sigurnosnih ciljeva te bi se morala mjeriti u kontekstu utroenog vremena i nastalih trokova u odnosu na vanost i vrijednost resursa. Obiljeja resursa koja pritom treba uzeti u obzir jesu njihova vrijednost i osjetljivost, te eventualna inherentna zatita. Funkcionalne i sigurnosne potrebe resursa ovise o njihovoj ranjivosti u prisutnosti odreene prijetnje.
1.4.2. Prijetnje Resursi su izloeni raznim vrstama prijetnja. Prijetnja moe prouzroiti neeljenu situaciju ija posljedica moe biti nanoenje tete resursima banke. Drugim rijeima, teta moe nastati kao posljedica ostvarenja prijetnje (primjerice neovlatenog unitavanja, razotkrivanja, promjene te unoenja promjena koje uzrokuju pogreno zapisivanje, nedostupnost ili gubitak informacija). Prijetnja mora iskoristiti postojeu ranjivost resursa da bi se realizirala i rezultirala tetom. Prijetnje mogu biti prirodne ili uzrokovane ljudskim djelovanjem (sluajne ili namjerne). Stoga je potrebno tono utvrditi prijetnje kao i njihovu razinu i vjerojatnost. Primjeri prijetnja prikazani su u tablici br. 1: Tablica br. 1 Primjeri prijetnja Ljudske Namjerne prislukivanje modifikacija informacija "hakiranje" maliciozni kod kraa Sluajne pogreke i propusti potres nenamjerno brisanje datoteka, udar groma podataka i sl. pogreno preusmjeravanje poplava nenamjerno fiziko unitenje poar Prirodne
Dostupni su statistiki podaci o mnogim vrstama prijetnja koje bi banka trebala pribaviti i iskoristiti prilikom procesa procjene ranjivosti u svezi s odreenom prijetnjom. Prijetnja se moe pojaviti unutar banke (primjerice u obliku sabotae nekog od zaposlenika) ili izvan nje, (primjerice u obliku zlonamjernih "hakera" ili industrijske pijunae). teta koju nanose takvi neeljeni dogaaji moe biti prolazne prirode ili trajna (u sluaju potpunog unitenja resursa). Opseg tete uzrokovane prijetnjom moe se razlikovati prema neeljenom dogaaju. Virus, kao primjer malicioznog koda, moe uzrokovati razliitu razinu tete ovisno o svom djelovanju. Prijetnje je esto mogue kvantificirati i/ili kvalificirati kako bi se ocijenila njihova razorna mo (primjerice virus se moe opisati kao destruktivan ili nedestruktivan, a jaina potresa moe se opisati na temelju Richterove ljestvice). Neke prijetnje mogu utjecati na vie od jednog resursa te mogu imati razliit uinak ovisno o kojem se resursu radi (primjerice virus na osobnom raunalu moe imati ograniene ili lokalne posljedice, dok uinak istog virusa na mrenom posluitelju moe biti puno iri). Svaka prijetnja ima obiljeja koja pruaju korisne informacije o samoj prijetnji. Primjeri takvih korisnih informacija ukljuuju: 1. izvor (primjerice je li rije o unutranjoj ili vanjskoj prijetnji) 2. motiv (primjerice ostvarivanje financijske dobiti, ostvarivanje konkurentske prednosti) 3. uestalost pojavljivanja 4. razornu mo. Prijetnje je mogue okarakterizirati prema razini i vjerojatnosti pojedine prijetnje (primjerice kao velike, srednje i male).
1.4.3. Ranjivost Ranjivost je slabost koju je mogue sluajno aktivirati ili namjerno iskoristiti, a posljedica toga moe biti nanoenje tete informacijskom sustavu i poslovnim ciljevima. Ranjivosti koje se povezuju s resursima ukljuuju, izmeu ostalog, slabosti fizike sigurnosti, organizacije, internih akata, zaposlenika, upravljake strukture, hardvera, softvera i informacija. Ranjivost sama po sebi ne nanosi tetu, nego ranjivost moemo definirati kao stanje ili skup stanja koji moe omoguiti nekoj prijetnji da utjee na resurse (primjerice nedostatak mehanizama kontrole pristupa jest ranjivost koja bi mogla omoguiti ostvarenje prijetnje neovlatenog pristupa, to moe dovesti do gubitka ili oteenja resursa). Budui da se okruenje moe brzo promijeniti, potrebno je pratiti sve oblike ranjivosti kako bi se identificirale one koje su postale izloene starim i novim prijetnjama. Analiza ranjivosti je procjena slabosti koje identificirane prijetnje mogu iskoristiti. Ta bi analiza trebala uzeti u obzir okruenje i postojee zatitne mjere i kontrole. Ranjivost u odnosu na neku prijetnju pokazatelj je lakoe kojom je mogue natetiti sustavu ili resursima. Ranjivost se moe okarakterizirati ovisno o ishodu analize ranjivosti (primjerice kao velika, srednja i mala).
10
1.4.4. Uinak Uinak je posljedica nekoga neeljenog dogaaja, izazvanog namjerno ili sluajno, koji utjee na resurse. Posljedice mogu biti unitenje nekog resursa, nanoenje tete informacijskom sustavu te gubitak temeljnih naela informacijskog sustava ega rezultat moe biti (to moe prouzroiti) financijski gubitak i gubitak trinog udjela ili reputacije banke. Uestalost pojave neeljenog dogaaja takoer treba uzeti u obzir, posebice kada je razina tete poinjene svakim dogaajem niska, ali ukupan uinak veeg broja dogaaja s vremenom moe biti znatan. Analiza uinka vaan je element procjene rizika i odabira zatitnih mjera. Kvantitativna i kvalitativna mjerenja uinka mogu biti provedena na razliite naine, kao to su: utvrivanje trokova pridruivanje neke empirijske skale za njegovo mjerenje (npr. od 1 do 10) upotreba unaprijed odreenog naina stupnjevanja (npr. mali, srednji i veliki).
1.4.5. Rizik Rizik je funkcija vjerojatnosti da e identificirani izvor prijetnje iskoristiti odreenu ranjivost i uinka koji taj neeljeni dogaaj moe imati na banku. Drugim rijeima, rizik obiljeava kombinacija dvaju faktora, a to su vjerojatnost da e se neeljeni dogaaj dogoditi te njegov uinak. Svaka promjena resursa, prijetnja, ranjivosti ili zatitnih mjera moe znatno utjecati na rizik. Rano otkrivanje te prepoznavanje promjena koje su nastale u okruenju ili sustavu poveava mogunost pravodobnog poduzimanja koraka potrebnih za smanjivanje rizika.
1.4.6. Mjere Mjere ukljuuju sve postupke, procedure i mehanizme kojima se: tite resursi informacijskog sustava od prijetnja; smanjuju ranjivosti informacijskog sustava; ograniava uinak neeljenih dogaaja; otkrivaju neeljeni dogaaji; pospjeuje oporavak. Budui da mjere smanjuju izloenost banke riziku, moemo ih smatrati i zatitnim mjerama. Zatitne se mjere odnose na upravljaku, logiku i fiziku razinu. Djelotvorno upravljanje informacijskim sustavom obino zahtijeva kombiniranje razliitih zatitnih mjera kako bi se osigurala slojevita zatita resursa informacijskog sustava. Zatitne mjere imaju jednu od sljedeih uloga ili vie njih: 1. prevencije 2. odvraanja 3. otkrivanja 4. ograniavanja
11
5. 6. 7. 8.
korigiranja oporavka nadzora osvjeivanja.
Zatitne se mjere provode uvoenjem novih ili izmjenom postojeih kontrola. Podizanje razine znanja i svijesti zaposlenika vezanih uz sigurnost i funkcionalnost informacijskog sustava vana je zatitna mjera.
1.4.7. Preostali rizici U veini sluajeva provedba zatitnih mjera ne uklanja u potpunosti rizike, to upuuje na postojanje preostalih (rezidualnih) rizika. Upravljake strukture trebaju biti svjesne svih preostalih rizika sa stajalita njihova mogueg uinka i vjerojatnosti pojave negativnog dogaaja, te donijeti odluku o prihvaanju preostalih rizika kojima je izloen informacijski sustav.
1.4.8. Ogranienja Pri odabiru i provedbi mjera potrebno je uzeti u obzir ogranienja kao to su: 1. organizacijska ogranienja 2. financijska ogranienja 3. ogranienja odreenog okruenja 4. ogranienja vezana uz ljudske resurse 5. vremenska ogranienja 6. pravna ogranienja 7. tehnika ogranienja 8. kulturoloka i drutvena ogranienja. Veinu navedenih ogranienja obino postavljaju upravljake strukture banke, te na njih utjee okruenje u kojem banka posluje. Isto tako, potrebno je periodino revidirati ogranienja kako bi se identificirala nova ogranienja i uoile promjene ve poznatih ogranienja.
12
2. Upravljanje informacijskim sustavom

Cilj upravljanja informacijskim sustavom jest podravanje poslovnih ciljeva i strategije banke uz efikasno koritenje resursa informacijskog sustava te primjereno upravljanje rizicima koji proizlaze iz koritenja informacijske tehnologije. Uspjeno upravljanje informacijskim sustavom rezultira postizanjem optimalnog uinka informacijske tehnologije, te naposljetku daje dodatnu vrijednost poslovanju. Nadalje, upravljanje informacijskim sustavom odnosi se na sve osobe, sustave i procese koji svojim aktivnostima vezanim uz informacijski sustav pridonose ispunjavaju poslovnih ciljeva i strategije banke, te postizanju i odravanju temeljnih naela informacijskog sustava. Primjereno upravljanje informacijskim sustavom ukljuuje, meu ostalim, i uspostavu: adekvatne organizacijske strukture (primjerice organizacijske jedinice za informacijsku tehnologiju, organizacijske jedinice za upravljanje rizikom) odgovarajuih funkcija i odbora (kao to su voditelj organizacijske jedinice za informacijsku tehnologiju, voditelj sigurnosti informacijskog sustava, odbor za upravljanje informacijskim sustavom) procesa upravljanja rizikom informacijskog sustava (procjene rizika, poduzimanje radnja za smanjenje rizika na prihvatljivu razinu i odravanje prihvatljive razine rizika) i nadzora nad tim procesom. Nadalje, upravljanje informacijskim sustavom treba obuhvatiti sljedea podruja: sigurnost informacijskog sustava planiranje kontinuiteta poslovanja razvoj sustava i eksternalizaciju odravanje informacijskog sustava. Banka bi trebala uspostaviti organizacijsku jedinicu za informacijsku tehnologiju koja bi trebala pruati adekvatnu informatiku podrku ostalim organizacijskim jedinicama. Pri odreivanju organizacijske strukture i definiranju funkcija organizacijske jedinice za informacijsku tehnologiju potrebno je osigurati adekvatnu podjelu zadataka i ovlasti. Navedeno je potrebno kako bi se osiguralo prikladno rasporeivanje resursa za sve funkcije organizacijske jedinice za informacijsku tehnologiju i adekvatno razdvajanje (segregiranje) dunosti. Upravljanje informacijskim sustavom banke trebalo bi biti predmetom nadzora unutarnje revizije kako bi se neovisno i objektivno provjerila adekvatnost upravljanja tim sustavom.
Strategija i planiranje Banka bi trebala donijeti strategiju informacijskog sustava koja treba biti usklaena s poslovnom strategijom banke. Strategija informacijskog sustava trebala bi obuhvatiti dugorone i kratkorone inicijative povezane s informacijskim sustavom, pri emu valja uzeti u obzir barem sljedee: nove poslovne inicijative organizacijske promjene tehnoloki razvoj
13
regulatorne zahtjeve potrebe za resursima i nadzorom ogranienja.
Nadalje, strategija informacijskog sustava trebala bi biti formalno dokumentirana, odobrena od strane uprave banke te aurirana i revidirana na godinjoj razini. Strategiju informacijskog sustava potrebno je razraditi donoenjem stratekih i operativnih planova. Strateko planiranje vezano uz informacijski sustav usredotoeno je na srednji rok te pomae osigurati dosljednost primjene i usklaenost tehnolokih planova s poslovnim ciljevima banke. Uspjeno strateko planiranje treba osigurati informatiku podrku kojom bi se odrala ravnotea trokova i djelotvornosti te istodobno omoguilo poslovnim organizacijskim jedinicama da adekvatno odgovore na zahtjeve trita. Isto tako, potrebno je procijeniti potrebna financijska sredstva. Prilikom planiranja informacijskih sustava potrebno je razmotriti barem sljedee imbenike: poslovne ciljeve i planove banke uvjete na tritu planirani rast banke tehnoloke standarde vaee propise kontrolu trokova unapreenje procesa i porast djelotvornosti kvalitetu usluga pruenih klijentima banke usporedbu eksternalizacije procesa i provoenja procesa unutar banke optimalnu infrastrukturu sposobnost usvajanja i uvoenja novih tehnologija ogranienja. Operativno planiranje proizlazi iz stratekog planiranja, usredotoeno je na kratkorone aktivnosti te ukljuuje i donoenje financijskog plana. S obzirom na prije navedeno operativno bi planiranje trebalo biti usredotoeno na neposredna pitanja kao to su postojanje adekvatnih resursa informacijskog sustava, dostatnost financijskih sredstava, adekvatno upravljanje rizikom te uinak moguih promjena na poslovne procese, kako bi se zadovoljile operativne potrebe. Strateke i operativne planove potrebno je meusobno prilagoavati, ovisno o promjenama poslovnih ciljeva.
Interni akti Donoenje i primjena internih akata vezanih uz informacijski sustav osnova su za uspostavljanje i odravanje upravljakih kontrola koje bi trebale biti slojevite i hijerarhijski uspostavljene od najvie (strateke) razine prema najnioj (operativnoj) razini. Banka bi trebala donijeti, dokumentirati, provoditi i odravati interne akte kako bi adekvatno upravljala rizicima koji proizlaze iz koritenja informacijske tehnologije te naposljetku kako bi djelotvorno upravljala informacijskim sustavom u cjelini. Internim aktima smatraju se odluke, politike, standardi, smjernice, procedure, upute i ostali dokumenti za ije je donoenje
14
odgovorna uprava banke. Interne akte potrebno je integrirati u procese informacijskog sustava i svakodnevne aktivnosti zaposlenika. Nadalje, interni bi akti trebali biti usklaeni s propisima, standardima i pravilima struke. Interni akti na najvioj konceptualnoj ili hijerarhijskoj razini (primjerice politike) trebali bi obuhvatiti sva podruja i aspekte informacijskog sustava banke ukljuujui osobe, sustave i procese. Banka bi trebala procijeniti i odrediti koja je podruja i aspekte informacijskog sustava potrebno razraditi detaljnijim internim aktima nie razine (primjerice smjernicama, uputama i procedurama) te definirati razinu detaljnosti razrade. Razina detaljnosti i obuhvat pojedinog internog akta ovise o njegovoj svrsi, namjeni, vrsti te o kompleksnosti informacijskog sustava.
15
2.1. Uprava banke

Upravljanje informacijskim sustavom vrlo je vano u procesu donoenja poslovnih odluka. Kako bi banka primjereno upravljala informacijskim sustavom, uprava bi banke, izmeu ostalog, trebala: biti upoznata s konceptima i aktivnostima vezanim uz informacijski sustav odrediti lana uprave koji e biti nadlean za nadzor i kontrolu procesa upravljanja informacijskim sustavom uspostaviti adekvatnu organizacijsku strukturu, pripadajue funkcije i odbore koji upravljaju informacijskim sustavom banke delegirati ovlasti prema uspostavljenoj organizacijskoj i funkcionalnoj strukturi definirati kriterije, naine i postupke izvjeivanja uprave usvojiti strategiju informacijskog sustava te nadzirati njezino provoenje donijeti interne akte kojima se ureuje upravljanje informacijskim sustavom uspostaviti proces upravljanja rizikom informacijskog sustava.
16
2.2. Voditelj organizacijske jedinice za informacijsku tehnologiju

Uprava banke trebala bi imenovati voditelja organizacijske jedinice za informacijsku tehnologiju (engl. Chief Information Officer) te definirati njegove ovlasti, odgovornosti kao i djelokrug rada. Voditelj organizacijske jedinice informacijske tehnologije trebao bi prvenstveno biti usmjeren na strateka pitanja vezana uz informacijski sustav, upravljanje, nadzor i koordinaciju rada organizacijske jedinice informacijske tehnologije te na funkcionalnost i djelotvornost informacijskog sustava u cjelini. Nadalje, voditelj organizacijske jedinice informacijske tehnologije trebao bi imati prikladno struno obrazovanje i znanje te odgovarajue iskustvo na podruju informacijske tehnologije i upravljanja njome. Dobre prakse nalau da djelokrug rada voditelja organizacijske jedinice za informacijsku tehnologiju obuhvaa sljedee: razvoj i odravanje informacijskog sustava pruanje podrke korisnicima informacijskog sustava sudjelovanje u izradi strategije i stratekog plana informacijskog sustava planiranje, organizaciju, koordinaciju i nadzor aktivnosti organizacijske jedinice za informacijsku tehnologiju pokretanje inicijativa (npr. unapreivanje postojeih funkcionalnosti informacijskog sustava, uvoenje novih tehnolokih rjeenja, unapreenje sigurnosti informacijskog sustava i slino) provedbu svih prihvaenih inicijativa koje banka poduzima u svezi s informacijskim sustavom koordiniranje aktivnosti vezanih uz sigurnost informacijskog sustava s voditeljem sigurnosti informacijskog sustava koordiniranje aktivnosti glede informacijskog sustava s ostalim organizacijskim jedinicama i tijelima banke planiranje ulaganja u informacijski sustav sudjelovanje u procesu odabira i nabave informatike opreme sudjelovanje u planiranju, provedbi i nadzoru eksternalizacije (dijela) informacijskog sustava sudjelovanje u izradi internih akata povezanih s informacijskim sustavom (politika, standarda, procedura, smjernica, uputa, planova) planiranje izobrazbe upravljanje imovinom informacijskog sustava upravljanje odnosom s dobavljaima izvjetavanje uprave banke ostalo (ovisno o procjeni i odluci uprave banke).
17
2.3. Voditelj sigurnosti informacijskog sustava

Banka bi trebala uspostaviti neovisnu funkciju voditelja sigurnosti informacijskog sustava (engl. Chief Information Systems Security Officer - CISSO). Voditelj sigurnosti informacijskog sustava ne bi trebao istodobno biti angairan na drugim funkcijama koje mogu stvoriti sukob interesa (kao to su rukovoditelj ili zaposlenik organizacijske jedinice za informacijsku tehnologiju i unutarnji revizor informacijskog sustava). Voditelj sigurnosti trebao bi biti odgovoran upravi banke te svoja izvjea dostavljati izravno upravi, a ukoliko procijeni da je potrebno, i nadzornom odboru banke. Nadalje, jednom godinje voditelj sigurnosti informacijskog sustava trebao bi za upravu i nadzorni odbor izraditi izvjee o stanju sigurnosti informacijskog sustava u proteklih godinu dana. Voditelj organizacijske jedinice za informacijsku tehnologiju i unutarnji revizor trebali bi biti upoznati s navedenim izvjeima. Voditelj sigurnosti informacijskog sustava trebao bi: nadzirati i koordinirati aktivnosti vezane uz sigurnost informacijskog sustava inicirati primjenu dobrih praksi i prihvaenih standarda vezanih uz sigurnost informacijskog sustava imati savjetodavnu ulogu u svezi sa sigurnosti informacijskog sustava. Zadaci voditelja sigurnosti trebali bi, izmeu ostalog, ukljuivati sljedee:
odreivanje sigurnosnih ciljeva u skladu sa strategijom informacijskog sustava banke razvoj politike sigurnosti informacijskog sustava, standarda, smjernica i ostalih internih akata s ciljem postizanja i odravanja zadovoljavajue razine sigurnosti razvoj i primjenu strategije sigurnosti i sigurnosne arhitekture informacijskog sustava nadziranje istrage u sluajevima naruavanja sigurnosti informacijskog sustava suradnju s vanjskim suradnicima prilikom obavljanja neovisnih revizija i testiranja sigurnosti informacijskog sustava analiziranje sigurnosnih potreba te u skladu s njima predlaganje planiranja, implementacije, testiranja i nadziranja aktivnosti za poboljanje sigurnosti informacijskog sustava planiranje i koordiniranje analize isplativosti preporuenih i postojeih sigurnosnih rjeenja upozoravanje na potrebu za izobrazbom i davanje smjernica za izobrazbu svih osoba koje se koriste informacijskim sustavom banke, a u svezi sa sigurnosti informacijskog sustava dostavljanje izvjea upravi i nadzornom odboru banke procjenu rizika sigurnosti informacijskog sustava kontroliranje provoenja politike sigurnosti informacijskog sustava i ostalih internih akata koji se odnose na sve aspekte sigurnosti informacijskog sustava koordiniranje aktivnosti s organizacijskom jedinicom informacijske tehnologije i unutarnjom revizijom sudjelovanje u znaajnijim fazama u ivotnom ciklusu informacijskog sustava s aspekta sigurnosti sudjelovanje u planiranju kontinuiteta poslovanja.
18
2.4. Odbor za upravljanje informacijskim sustavom

Uprava banke trebala bi imenovati odbor za upravljanje informacijskim sustavom ija je uloga praenje i nadziranje informacijskog sustava i njegovih aktivnosti u smislu usklaenosti s poslovnim ciljevima i stratekim planom banke. Isto tako, uloga odbora za upravljanje informacijskim sustavom jest koordinacija inicijativa vezanih uz informacijski sustav na upravljakoj razini, omoguavanje optimizacije trokova i boljeg upravljanja informacijskim sustavom te smanjivanje rizika informacijskog sustava. Opseg djelovanja, ovlasti i ciljevi odbora za upravljanje informacijskim sustavom moraju biti jasno definirani. Aktivnosti odbora za upravljanje informacijskim sustavom trebale bi ukljuiti barem sljedee: koordiniranje i nadzor razvoja i primjenu strategije i stratekog plana informacijskog sustava ocjenjivanje i prihvaanje politike sigurnosti informacijskog sustava kako bi se osiguralo da politika sigurnosti odgovara poslovnim zahtjevima i ne ograniava poslovne aktivnosti odobravanje i kontrolu vanijih projekata vezanih uz informacijski sustav, kao i sredstava potrebnih za njihovu realizaciju postavljanje prioriteta vanih aktivnosti vezanih uz informacijski sustav predlaganje novih te ocjenjivanje postojeih internih akata koji se odnose na informacijski sustav nadziranje funkcionalnosti i sigurnosti informacijskog sustava u cjelini ovisno o potrebi, predlaganje ulaganja u informacijski sustav koja odstupaju od planiranih trokova arbitriranje u sluaju nesuglasica i spornih pitanja povezanih s informacijskim sustavom procjenjivanje i odobravanje eksternalizacije (dijela) poslovnih procesa te koordiniranje aktivnosti vezanih uz eksternalizaciju koordiniranje, nadzor i potvrivanje klasifikacije informacija podnoenje izvjea upravi banke o svom radu davanje miljenja o imenovanju voditelja sigurnosti informacijskog sustava. Odbor za upravljanje informacijskim sustavom trebao bi dobivati potrebne informacije od organizacijske jedinice za informacijsku tehnologiju i ostalih organizacijskih jedinica te unutarnje i vanjske revizije kako bi mogli djelotvorno koordinirati i kontrolirati resurse informacijskog sustava. Odbor za upravljanje informacijskim sustavom trebao bi se redovito sastajati te sastavljati zabiljeke radi dokumentiranja svojih aktivnosti i odluka. Dobre prakse nalau da lanovi odbora za upravljanje informacijskim sustavom budu: lan uprave banke rukovoditelj organizacijske jedinice za informacijsku tehnologiju voditelj sigurnosti informacijskog sustava osoba koja obavlja unutarnju reviziju informacijskog sustava (djelovanje te osobe u odboru ne bi smjelo stvoriti sukob interesa utjecanjem na proces donoenja odluka) predstavnici ostalih organizacijskih jedinica banke, odnosno barem onih organizacijskih jedinica koje su izrazito ovisne o informacijskom sustavu.
19
Sve navedene aktivnosti odbora za upravljanje informacijskim sustavom mogu provoditi i drugi odbori u skladu s potrebama i odlukom uprave banke.
20
2.5. Upravljanje projektima

Dobre prakse nalau primjenu projektnog pristupa za postizanje specifinih ciljeva u okviru upravljanja informacijskim sustavom banke. Upravljanje projektima je primjena znanja, vjetina, alata i jasno definiranih te provjerenih tehnika na razliite aktivnosti za potrebe projekata. Upravljanje projektima podrazumijeva uspostavu procesa planiranja, organizacije, provedbe i kontrole osoba, sustava i procesa radi postizanja postavljenih ciljeva. Detaljni projektni planovi, jasno postavljeni zahtjevi i oekivanja, iskustvo voditelja projekata, realan budet i djelotvorna komunikacija uvelike pridonose uspjenom upravljanju projektima. Neprimjereno voenje projekata moe rezultirati, primjerice, kanjenjem projekta, prekoraenjem budeta projekta ili smanjenom kvalitetom proizvoda ili usluge. Smanjena kvaliteta proizvoda ili usluge moe se oitovati u problemima s pouzdanou, djelotvornou ili sigurnou, a svaka naknadna promjena koja unapreuje sigurnost, funkcionalnost i sustav kontrola u cjelini moe zahtijevati dodatne resurse (primjerice novac, ljude, vrijeme). Adekvatno upravljanje projektima omoguava banci razvoj novih proizvoda i usluga te irenje poslovanja u skladu sa stvarnim potrebama, pravodobno i u okviru planiranih financijskih i ljudskih resursa. Drugim rijeima, primjereno upravljanje projektima poveava sposobnost banke prilagoavanju promjenama u poslovanju i okruenju te omoguuje ostvarivanje postavljenih stratekih ciljeva. Uzimajui u obzir sloenost i posebnost projekata i poslovnih procesa, banka bi trebala definirati i formalno propisati proces upravljanja projektima. Metodologija upravljanja projektima (strukturirane tehnike voenja projekata koje ukljuuju naela, prakse i procedure) unapreuje kontrolu nad projektima dijelei sloene zadatke u manje cjeline kojima je lake upravljati. Metodologija upravljanja projektima trebala bi segmentirati projekte u projektne faze ovisno o odabiru metodologije (primjerice faza inicijacije projekta, planiranja, dizajniranja, razvoja, testiranja, implementacije i odravanja) kao i potrebne aktivnosti unutar projektnih faza. Isto tako, metodologija upravljanja projektima trebala bi se moi prilagoditi karakteristikama pojedinih projekata. Metodologija upravljanja projektima trebala bi definirati kriterije, naine i postupke upravljanja projektima odnosno osigurati postojanje adekvatnih: projektnih planova definicija zahtjeva i oekivanja od projekta standarda voenja projekta i procedura standarda kontrole kvalitete i upravljanja rizikom projekta definicija projektnih uloga i odgovornosti financijskih, vremenskih i ljudskih resursa kontrolnih toaka kanala i naina komunikacije.
21
Dobre prakse nalau primjenu projektnog pristupa prilikom: nabave, eksternalizacije i razvoja (dijela) informacijskog sustava ostalih aktivnosti kao to su migracija sustava i podataka, unapreivanje proizvoda, usluga i infrastrukture. Radi primjerenog upravljanja projektima vrlo je vano jasno definirati uloge i odgovornosti svih osoba i tijela ukljuenih u realizaciju projekata kao to su uprava banke, odbor za upravljanje informacijskim sustavom, voditelj projekta, sponzor projekta, organizacijska jedinica za informacijsku tehnologiju, kontrola kvalitete, zaposlenici iz poslovnih sektora, sistemski analitiari i tehnolozi poslovnih procesa, unutarnja revizija te voditelj sigurnosti informacijskog sustava. Ovisno o veliini i sloenosti projekta i samih poslovnih procesa uloge se mogu preklapati pri emu treba uzeti u obzir potrebu za primjerenom segregacijom dunosti. U svim projektnim fazama potrebno je obratiti pozornost na sigurnosne aspekte projekta te na zahtjeve koji proizlaze iz potrebe za odravanjem kontinuiteta poslovanja.
22
3. Upravljanje rizikom informacijskog sustava

Upravljanje rizikom je proces procjene rizika, poduzimanja radnja za smanjenje rizika na prihvatljivu razinu i odravanja prihvatljive razine rizika. Drugim rijeima, upravljanje rizikom kontinuirani je proces usporedbe procijenjenih rizika s prednostima i trokovima predloenih mjera te uvoenja odabranih mjera u skladu s poslovnim ciljevima i temeljnim naelima informacijskog sustava. Upravljanje rizikom treba obuhvatiti cjelokupni informacijski sustav banke. Za nove sustave i sustave koji su u fazi planiranja (ukljuujui i planiranje znaajnih promjena u informacijskom sustavu), upravljanje rizikom treba biti sastavni dio razvojnog procesa, dok se kod postojeih sustava treba uvesti u to kraem vremenu. Zatitne mjere se odabiru ovisno o rizicima odnosno o vjerojatnosti pojave neeljenog dogaaja i o njegovu uinku na informacijski sustav. Takoer je vano napomenuti da provoenje zatitnih mjera moe stvoriti nove ranjivosti i tako rezultirati novim rizicima. Stoga je potrebno pomno izabrati odgovarajue zatitne mjere, ne samo radi smanjivanja rizika ve i zato da bi se izbjeglo izlaganja novim rizicima. Isto tako, potrebno je razmotriti razliite vrste zatitnih mjera i provesti analizu isplativosti te uzeti u obzir prihvatljivu razinu rizika preostalih nakon provoenja odabranih mjera odnosno uvoenja kontrola. Rizici se procjenjuju s aspekta mogueg uinka kao posljedice naruavanja funkcionalnosti i sigurnosti informacijskog sustava, odnosno naruavanja temeljnih naela informacijskog sustava. Veina prijetnja i ranjivosti neposredno se odnosi na sigurnost informacijskog sustava stoga je u nastavku ovog dokumenta poseban naglasak stavljen na procjenu i smanjenje rizika s aspekta sigurnosti. Kako bi se postigla zadovoljavajua razina sigurnosti, banka bi trebala utvrditi sigurnosni potencijal kojim treba raspolagati informacijski sustav te planirati sredstva za njegovo ostvarenje. Upravljanje rizikom omoguuje uravnoteivanje operativnih trokova i koristi od zatitnih mjera da bi se adekvatno zatitio informacijski sustav. Upravljanje rizikom je kontinuirani proces koji ukljuuje: procjenu rizika smanjivanje rizika odravanje prihvatljive razine rizika. Dobre prakse nalau da se upravljanje rizikom integrira u ivotni ciklus informacijskog sustava kako bi procijenjeni rizik odgovarao stvarnom stanju sustava te kako bi se podrali poslovni ciljevi banke. U sljedea dva poglavlja ukratko su opisane radnje koje bi banka, prema dobrim praksama, trebala poduzimati u sklopu upravljanja rizicima. Spomenute su radnje samo jedan od naina provoenja procjene i smanjenja rizika.
23
3.1. Procjena rizika

Banka bi trebala pri procjeni rizika utvrditi razinu rizika kojem je izloen informacijski sustav te predloiti zatitne mjere kako bi se rizik smanjio na prihvatljivu razinu. Rizici se procjenjuju s aspekta mogueg uinka uzrokovanog naruavanjem funkcionalnosti i/ili sigurnosti informacijskog sustava. Kako bi se utvrdila vjerojatnost pojave nekog tetnog dogaaja, potrebno je analizirati prijetnje informacijskom sustavu zajedno s ranjivostima te kontrolama koje su primijenjene u informacijskom sustavu. Uinak se odnosi na opseg i veliinu tete koju prijetnja moe uzrokovati ako iskoristi odreenu ranjivost. Procjena rizika trebala bi ukljuivati sljedee radnje: 1. odreivanje obiljeja sustava 2. identifikaciju prijetnja 3. identifikaciju ranjivosti 4. analizu sustava kontrola 5. odreivanje vjerojatnosti 6. analizu uinka 7. utvrivanje rizika 8. predlaganje mjera 9. dokumentiranje rezultata u obliku formalnog izvjea.
3.1.1. Odreivanje obiljeja sustava Odreivanje obiljeja informacijskog sustava definira opseg procesa procjene rizika te daje informacije kljune za definiranje rizika. Utvrivanje rizika kojem je izloen informacijski sustav zahtijeva razumijevanje njegova okruenja. Stoga je potrebno prikupiti informacije o informacijskom sustavu koje ukljuuju: hardver softver sistemska suelja (npr. interna i eksterna sposobnost povezivanja) poslovne informacije i ostale informacije koje rabi informacijski sustav (informacije je potrebno klasificirati u razliite grupe prema stupnju njihove osjetljivosti, to je detaljnije opisano u poglavlju "Klasifikacija informacija") osobe koje odravaju i koriste informacijski sustav svrhu sustava (npr. procesi koje obavlja informacijski sustav) vanost i osjetljivost sustava i podataka (npr. vrijednost sustava ili kolika je njegova vanost za banku) ostalo. Nadalje, potrebno je prikupiti i dodatne informacije povezane s operativnim okruenjem informacijskog sustava koje ukljuuju sljedee (ali nisu ograniene na to): funkcionalne potrebe interne akte koji se odnose na informacijski sustav arhitekturu sigurnosti sustava topologiju mree (npr. dijagram mree)
24
tok informacija koje se odnose na informacijski sustav (npr. sistemska suelja, dijagram toka ulaznih i izlaznih podataka sustava) identifikaciju upravljakih, logikih i fizikih kontrola fiziku sigurnost (npr. sigurnost prostorija, politike pristupa sistemskoj prostoriji) sigurnost okoline u kojoj je informacijski sustav (npr. kontrola vlanosti, vode, napajanja, oneienja, temperature i kontrola prisutnosti kemikalija).
Rezultat: izvjee o obiljejima informacijskog sustava s cjelovitim prikazom okruenja informacijskog sustava
3.1.2. Identifikacija prijetnja Prijetnja je potencijal odreenog izvora prijetnja da uspjeno iskoristi odreenu ranjivost. Izvor prijetnje ne utjee na rizik ako ne moe iskoristiti ranjivost. Cilj identifikacije prijetnja jest otkriti prijetnje koje se odnose na informacijski sustav koji se procjenjuje, identificirati izvore prijetnja (ako je to mogue) te sastaviti popis identificiranih prijetnja i izvora. Prijetnja je: namjera ili radnja usmjerena k namjernom iskoritavanju ranjivosti sustava ili situacija ili radnja koja moe sluajno aktivirati ranjivost. Izvor prijetnje moe nanijeti tetu informacijskom sustavu. Uobiajeni izvori prijetnja mogu biti prirodni, ljudski ili iz okruenja. Stoga je potrebno identificirati sve prijetnje i izvore prijetnja koji bi mogli natetiti informacijskom sustavu banke i njegovu okruenju. Rezultat: izvjee s popisom prijetnja koje bi mogle iskoristiti ranjivosti informacijskog sustava banke i njihovih izvora
3.1.3. Identifikacija ranjivosti Ranjivost je slabost koju je mogue sluajno aktivirati ili namjerno iskoristiti. Sa stanovita sigurnosti informacijskog sustava ranjivost je mana ili slabost u sigurnosnim procedurama sustava, njegovu dizajnu, implementaciji ili unutarnjim kontrolama, koja moe biti iskoritena te rezultirati povredom sigurnosti. Cilj identifikacije ranjivosti jest utvrivanje ranjivosti informacijskog sustava koje bi mogli iskoristiti izvori prijetnja. Ranjivosti informacijskog sustava mogu biti otkrivene pomou razliitih metoda prikupljanja informacija. Pri analizi ranjivosti potrebno je, izmeu ostalog, uzeti u obzir sljedee: dokumentaciju o prethodnoj procjeni rizika informacijskog sustava izvjea unutarnje i vanjske revizije informacijskog sustava izvjea o nepravilnostima u sustavu izvjea o sigurnosti izvjea o testiranju informacijskog sustava
25
popise ranjivosti strune publikacije vezane uz informacijske sustave preporuke dobavljaa i proizvoaa izvjea o rezultatima testiranja informacijskog sustava pomou proaktivnih metoda testiranja (primjerice alata za automatsko otkrivanje ranjivosti, testiranje mogunosti prodora u sustav i slino).
Kao metoda u otkrivanju ranjivosti moe posluiti i izrada kontrolne liste zahtjeva koja sadri osnovne funkcionalne i sigurnosne kriterije koje je potrebno provjeriti kako bi se utvrdile ranjivosti resursa informacijskog sustava. Pri otkrivanju ranjivosti mogu se primijeniti kriteriji u sljedeim sigurnosnim segmentima: upravljakom (primjerice dodjela ovlasti i odgovornosti, procjena rizika) logikom (primjerice kontrole pristupa, komunikacija, operativni i sistemski zapisi) fizikom (primjerice kontrola i zatita okoline, fiziki pristup i raspolaganje medijima s podacima). Rezultat: izvjee s popisom identificiranih ranjivosti informacijskog sustava koje prijetnje mogu iskoristiti
3.1.4. Analiza sustava kontrola Cilj ove radnje jest analizirati sustav kontrola koje je banka uvela ili planira uvesti radi smanjenja ili otklanjanja vjerojatnosti (ili mogunosti) da neka prijetnja iskoristi ranjivost informacijskog sustava. Analiza sustava kontrola ukljuuje ispitivanje djelotvornosti kontrola koje su ve primijenjene u informacijskom sustavu. Sastavljanje kontrolne liste zahtjeva i/ili upotreba dostupne kontrolne liste moe biti od velike pomoi pri djelotvornom i sistematinom analiziranju sustava kontrola. Rezultat: izvjee s popisom kontrola i ocjenom njihove djelotvornosti
3.1.5. Utvrivanje vjerojatnosti Kako bi banka mogla utvrditi vjerojatnost da identificirana ranjivost bude iskoritena u okruenju izloenom prijetnji, potrebno je uzeti u obzir barem sljedee imbenike: motivaciju i sposobnost izvora prijetnje znaajke odreene ranjivosti postojanje i djelotvornost postojeih kontrola. Vjerojatnost da izvor prijetnje iskoristi ranjivost moe se iskazati pridruivanjem neke empirijske skale za mjerenje vjerojatnosti (npr. od 0 do 1) ili upotrebom unaprijed odreenog naina stupnjevanja kao npr. mala, srednja i velika vjerojatnost. Rezultat: ocjena vjerojatnosti
26
3.1.6. Analiza uinka Analiza uinka je procjenjivanje negativnog uinka koji bi mogao nastati ukoliko prijetnja uspjeno iskoristi ranjivost. Osnovne informacije potrebne za analizu uinka ukljuuju barem sljedee: svrhu sustava (primjerice procesa koje obavlja informacijski sustav) vanost sustava i podataka za poslovanje banke osjetljivost podataka i sustava. Navedene informacije mogue je dobiti iz analize utjecaja na poslovanje, klasifikacije informacija te prikupljanjem informacija od zaposlenika i ostalih izvora. Na temelju dobivenih informacija potrebno je procijeniti negativan uinak nekog neeljenog dogaaja. Negativan uinak dogaaja mogue je opisati kao naruavanje funkcionalnosti ili gubitak odnosno kompromitiranje bilo kojeg temeljnog naela informacijskog sustava ili kombinacije tih naela. Pojedine uinke mogue je mjeriti kvantitativno, u obliku izgubljenog prihoda, trokova popravka sustava ili vremena koje je potrebno uloiti kako bi se rijeili problemi nastali izvrenjem prijetnje. Drugi uinci (npr. gubitak povjerenja javnosti, gubitak kredibiliteta, teta nainjena interesima banke) ne mogu se mjeriti odreenim mjernim jedinicama, ali ih je mogue odrediti ili opisati kvalitativno (npr. kao male, srednje i velike uinke). Rezultat: izvjee o procijenjenoj razini uinka
3.1.7. Utvrivanje rizika Svrha ove radnje jest procijeniti razinu rizika kojem je izloen informacijski sustav banke. Utvrivanje rizika izloenosti odreenoj kombinaciji prijetnje i ranjivosti moe se izraziti kao funkcija: vjerojatnosti da e identificirani izvor prijetnje iskoristiti odreenu ranjivost jaine (razine) uinka ako izvor prijetnje uspjeno iskoristi ranjivost. Prilikom utvrivanja razine rizika potrebno je uzeti u obzir i prikladnost planiranih ili postojeih kontrola za smanjivanje ili uklanjanje rizika te uestalost pojave neeljenih dogaaja. Jedan od naina mjerenja rizika jest izrada matrice razine rizika i ljestvice rizika.
Matrica razine rizika Razina rizika utvruje se mnoenjem ocjene koja je dodijeljena vjerojatnosti da izvor prijetnje iskoristi ranjivost s ocjenom uinka neeljenog dogaaja, pri emu se uzima u obzir prikladnost planiranih ili postojeih kontrola. Tablica br. 2 daje jednostavan primjer kako se mogu odrediti rizici na temelju podataka o vjerojatnosti da izvor prijetnje iskoristi ranjivost i o uinku.
27
Primjer u tablici br. 2 jest matrica vjerojatnosti da izvor prijetnje iskoristi ranjivost (velika, srednja i mala) i uinka (velikog, srednjeg i malog), koja prikazuje kako se rauna ukupna razina rizika. Na primjer: ocjena vjerojatnosti da izvor prijetnje iskoristi ranjivost koja se pripisuje svakoj razini vjerojatnosti prijetnje jest 1,0 za veliku, 0,5 za srednju i 0,1 za malu; ocjena uinka koja se dodjeljuje svakoj razini jaine uinka jest 100 za veliku, 50 za srednju i 10 za malu. Ovisno o potrebama i detaljnosti procjene rizika moe se koristiti matrica proizvoljnih dimenzija. Tablica br. 2 Matrica razine rizika (engl. Risk-Level Matrix) Vjerojatnost da izvor prijetnje iskoristi ranjivost Velika (1,0) Srednja (0,5) Mala (0,1) Uinak Srednji (50) 50 x 1,0 = 50 50 x 0,5 = 25 50 x 0,1 = 5
Mali (10) 10 x 1,0 = 10 10 x 0,5 = 5 10 x 0,1 = 1
Veliki (100) 100 x 0,5 = 50 100 x 0,1 = 10
Ljestvica rizika Tablica br. 3 opisuje razine rizika prikazane u tablici br. 2. Ljestvica rizika s pripadajuim ocjenama predstavlja stupanj ili razinu rizika kojem su izloeni resursi informacijskog sustava ako je iskoritena odreena ranjivost. Stupanj ili razina rizika odreuje aktivnosti koje bi se trebale poduzeti. Tablica br. 3 Primjer ljestvice rizika i aktivnosti koje je potrebno poduzeti Razina rizika Velik rizik (vei od 51) Opis rizika i aktivnosti koje je potrebno poduzeti Ako je rizik procijenjen kao velik, nuno je hitno provoenje mjera za smanjenje rizika. Postojei sustav moe nastaviti raditi, ali nuno je u to kraem roku sastaviti plan provoenja mjera te odrediti prioritete i rokove. Ako je rizik procijenjen kao srednji, nuno je provoenje mjera za smanjenje rizika. Potrebno je sastaviti plan provoenja mjera kako bi se one provele u razumnom vremenu. Ako je rizik procijenjen kao malen, potrebno je utvrditi je li nuno provoenje mjera za smanjenje rizika ili se rizik moe prihvatiti.
Srednji rizik (11 do 50)
Malen rizik (1 do 10)
Ako je razina nekih elemenata (vjerojatnosti, uinka ili rizika) tako mala da se moe okarakterizirati kao ''zanemariva'' ili nevana (primjerice vrijednost je < 1 na ljestvici od 0 do 100), potrebno ju je posebno zabiljeiti. Time se osigurava da isti elementi budu ukljueni u sljedeu procjenu. Navedeno je posebno vano jer ''zanemarivi'' rizici mogu s vremenom prerasti u rizike zbog kojih je potrebno poduzeti odreene aktivnosti.
28
Rezultat: matrica razine rizika ljestvica rizika i aktivnosti koje je potrebno poduzeti
3.1.8. Predlaganje mjera Predloene mjere jedan su od rezultata procesa procjene rizika. Cilj predloenih mjera jest smanjiti razinu rizika kojem je izloen informacijski sustav na prihvatljivu razinu. Prilikom predlaganja mjera za smanjenje ili otklanjanje utvrenih rizika treba uzeti u obzir, izmeu ostalog, sljedee imbenike: djelotvornost predloenih mjera vaee propise interne akte banke utjecaj na poslovne procese utjecaj na temeljna naela informacijskog sustava. U procesu smanjenja rizika odabiru se najprikladnije predloene mjere te se slijedom toga provode uvoenjem novih ili izmjenom postojeih kontrola. Rezultat: izvjee o predloenim mjerama za smanjivanje rizika
3.1.9. Izvjee o procjeni rizika Nakon zavretka procjene rizika (odreena su obiljeja sustava, identificirane prijetnje i ranjivosti, procijenjeni rizici te predloene mjere) potrebno je dokumentirati rezultate u obliku formalnog izvjea. Izvjee o procjeni rizika pomae upravi banke i drugim odgovornim osobama da donesu odluke o promjenama internih akata i prorauna te odluke o operativnim i upravljakim promjenama. Izvjee o procjeni rizika trebalo bi biti sastavljeno na sistematian, analitian i afirmativan nain koji e upravi banke omoguiti prepoznavanje rizika i promovirati potrebu alociranja sredstva kako bi utvreni rizici bili smanjeni na prihvatljivu razinu, a potencijalni gubici izbjegnuti. Rezultat: izvjee o procjeni rizika
29
3.2. Smanjivanje rizika

Smanjivanje rizika ukljuuje odreivanje prioriteta, procjenu, odabir i provoenje adekvatnih zatitnih mjera za smanjivanje rizika (predloenih u sklopu procesa procjene rizika) s obzirom na uestalost pojave neeljenih dogaaja i njihov uinak. Budui da je uklanjanje svih rizika kojima je izloen informacijski sustav gotovo nemogue, banka bi trebala poduzeti sve potrebne radnje kako bi smanjila rizik informacijskog sustava na prihvatljivu razinu provoenjem adekvatnih zatitnih mjera. Prilikom provoenja mjera potrebno je posebnu pozornost posvetiti smanjenju najznaajnijih rizika (kombinacija prijetnja i ranjivosti koje mogu potencijalno uzrokovati znaajan negativan uinak) na prihvatljivu razinu uz najmanji mogui utjecaj na ostale poslovne procese. Smanjivanje rizika identificiranih u procesu procjene rizika moe se postii na sljedee naine: Izbjegavanjem rizika. Izbjegavanje rizika uklanjanjem uzroka rizika i/ili posljedica (npr. odriui se odreenih funkcija sustava ili prestankom koritenja sustava kad su rizici otkriveni). Ograniavanjem rizika. Ograniavanje rizika provoenjem mjera (npr. primjenom preventivnih i detekcijskih kontrola) kojima se smanjuju potencijalni negativni uinci na prihvatljivu razinu. Prenoenjem rizika. Prenoenje rizika pomou drugih naina naknade pretrpljene tete (npr. ugovaranjem osiguranja). Pri odabiru bilo koje od ovih mogunosti smanjenja rizika potrebno je uzeti u obzir poslovne ciljeve i zadatke banke te potrebu za ouvanjem temeljnih naela informacijskog sustava. Ukoliko banka u procesu procjene rizika utvrdi da je rizik prihvatljiv, odnosno da nije potrebno njegovo daljnje smanjivanje, navedeni je rizik mogue prihvatiti donoenjem odluke o prihvaanju preostalih rizika. Smanjivanje rizika trebalo bi obuhvatiti sljedee radnje: 1. odreivanje prioriteta aktivnosti 2. procjenu predloenih mjera za smanjivanje rizika 3. provoenje analize isplativosti 4. odabir mjera za smanjivanje rizika 5. dodjeljivanje odgovornosti 6. izradu plana provoenja odabranih mjera 7. utvrivanje preostalih rizika.
3.2.1. Odreivanje prioriteta aktivnosti Prioriteti provoenja aktivnosti odreuju se na temelju utvrenih razina rizika sadranih u ljestvici rizika i u izvjeu o procjeni rizika. Viim razinama rizika dodijelit e se vii prioriteti (primjerice aktivnosti povezane s rizikom kojem je dodijeljena ocjena rizika vrlo visok ili visok, imat e najvii prioritet). U skladu s dodijeljenim prioritetima potrebno je provesti mjere kako bi se smanjili rizici kojima je izloen informacijski sustav i zatitili poslovni ciljevi. Rezultat: popis aktivnosti ocijenjenih prema prioritetima
30
3.2.2. Procjena predloenih mjera za smanjivanje rizika Pri procjenjivanju predloenih mjera potrebno je analizirati njihovu izvedivost (npr. kompatibilnost, prihvaanje od strane korisnika) i djelotvornost (npr. stupanj zatite i razinu smanjivanja rizika) zato to neke od predloenih mjera nisu uvijek i najprikladnija ili najisplativija rjeenja za banku i informacijski sustav. Cilj je ove radnje odabrati najprikladniju mjeru kako bi se rizik smanjio na prihvatljivu razinu. Rezultat: popis prikladnih mjera
3.2.3. Provoenje analize isplativosti Analiza isplativosti prikladnih mjera provodi se kako bi se olakalo donoenje odluka i utvrdila isplativost provoenja navedenih mjera. Rezultati analize mogu se iskazati kvalitativno ili kvantitativno. Svrha takve analize jest utvrivanje mjera iji e trokovi provoenja biti opravdani smanjenjem razine rizika na prihvatljivu razinu. Rezultat: izvjee o analizi isplativosti koja opisuje trokove i prednosti provoenja mjera ili razloge zbog kojih mjere nisu isplative
3.2.4. Odabir mjera za smanjivanje rizika Svrha ove radnje jest odabrati najdjelotvornije mjere za smanjivanje rizika. Odabrane mjere trebale bi kombinirati upravljake, logike i fizike elemente. Rezultat: popis odabranih mjera za smanjivanje rizika
3.2.5. Dodjeljivanje odgovornosti Svrha ove radnje jest odabir osoba (zaposlenika banke ili vanjskih suradnika) koje raspolau adekvatnim znanjem i vjetinama potrebnim za provoenje odabranih mjera te dodjeljivanje odgovornosti za provoenje mjera. Rezultat: popis dodijeljenih odgovornosti
3.2.6. Izrada plana provoenja odabranih mjera Svrha ove radnje jest izrada plana prema kojem e se provoditi odabrane mjere za smanjenje rizika. Provoenje odabranih mjera ostvaruje se uvoenjem novih ili izmjenom postojeih kontrola. Plan provoenja odabranih mjera treba sadravati barem sljedee: rizike (kombinacije ranjivosti i prijetnja) i pripadajue razine rizika (rezultate izvjea o procjeni rizika) 31
predloene mjere (rezultat izvjea o predloenim mjerama za smanjivanje rizika) ocjenu prioriteta (u skladu s razinama rizika) odabrane mjere (na temelju popisa odabranih mjera za smanjivanje rizika) resurse potrebne za provoenje odabranih zatitnih mjera popise odgovornih osoba datume poetka i zavretka provedbe odabranih zatitnih mjera.
Rezultat: plan provoenja odabranih mjera
3.2.7. Utvrivanje preostalih rizika U veini sluajeva provedene mjere za smanjivanje rizika rezultiraju smanjenjem, ali ne i potpunim otklanjanjem rizika, to upuuje na postojanje preostalih (rezidualnih) rizika. Nakon provoenja odabranih mjera potrebno je utvrditi preostale rizike te donijeti odluku o prihvaanju preostalih rizika ili poduzimanju radnja za daljnje smanjenje rizika. Rezultat: popis preostalih (rezidualnih) rizika
32
3.3. Kontrole
Provoenje odabranih mjera za smanjivanje rizika ostvaruje se uvoenjem novih ili izmjenom postojeih kontrola. Kontrole je mogue podijeliti na sljedee tri kategorije: upravljake, logike (tehnike) i fizike. Budui da je informacijski sustav siguran onoliko koliko je siguran njegov najranjiviji dio, nuan je slojevit pristup u izgradnji sigurnosne infrastrukture, koji ukljuuje razliite kombinacije upravljakih, logikih i fizikih kontrola. Koritenjem navedenih kategorija kontrola znaajno se smanjuje rizik od naruavanja temeljnih naela informacijskog sustava. Pravilnim provoenjem kontrola mogue je sprijeiti ili ograniiti tetu koju izvor prijetnje moe nanijeti banci, odnosno smanjiti rizik informacijskog sustava. Kontrole (slino kao i zatitne mjere) dijele se i prema njihovim ulogama na kontrole: 1. prevencije 2. odvraanja 3. otkrivanja 4. ograniavanja 5. korigiranja 6. oporavka 7. nadzora 8. osvjeivanja.
3.3.1. Upravljake kontrole Upravljake se kontrole provode donoenjem i primjenom internih akata radi osiguranja funkcionalnosti i sigurnosti te ouvanja temeljnih naela informacijskog sustava banke. Primjeri upravljakih kontrola jesu: dodjeljivanje odgovornosti razvijanje i odravanje politike sigurnosti informacijskog sustava te ostalih internih akata vezanih uz informacijski sustav uvoenje sigurnosne kontrole zaposlenika (primjerice razdvajanje dunosti, princip dodjeljivanja prava koritenja informacijskog sustava samo do razine koja je nuno potrebna za izvravanje radnih zadataka, dodjeljivanje posebnih dozvola, rotacija dunosti te dodjeljivanje i ukidanje prava pristupa informacijskom sustavu) kontrole vezane uz radnje koje je potrebno provoditi prilikom zapoljavanja, prekida radnog odnosa, premjetaja u drugu organizacijsku jedinicu i promaknua provoenje izobrazbe te podizanje razine svijesti o rizicima informacijskog sustava kako bi se osiguralo da krajnji korisnici i ostali korisnici sustava budu upoznati s njima te s pravilima ponaanja i odgovornostima provoenje periodinih nadzora i provjera djelotvornosti kontrola provoenje periodine revizije informacijskog sustava uspostava kontinuiranog procesa upravljanja rizikom radi procjene i smanjenja rizika uspostava procesa planiranja kontinuiteta poslovanja provoenje testiranja.
33
3.3.2. Logike kontrole Kontrole na softverskim i hardverskim komponentama informacijskog sustava nazivamo logikim kontrolama. Primjeri logikih kontrola jesu: softverske i hardverske kontrole za utvrivanje autentinosti, autorizaciju, provoenje obavezne kontrole pristupa te osiguranje neporecivosti radnja, zatienosti komunikacijskih kanala i povjerljivosti transakcija kontrole pristupa informacijskom sustavu kao to su: kombinacija korisnikoidentifikacijske oznake i zaporke, PKI infrastruktura, biometrijske kontrole, autentifikacija pomou "pametne kartice" (engl. smart card) i slino upotreba kriptografskih metoda u svrhu zatite informacija u postupku njihovog prijenosa kroz telekomunikacijsku mreu, te za vrijeme pohrane upotreba sistemskih i operativnih zapisa kako bi se biljeile aktivnosti koje su uinjene unutar telekomunikacijske mree, na mrenom ureaju ili na pojedinom raunalu upotreba usmjernika, preklopnika, vatrozida i ostalih mrenih komponenata u svrhu kontrole pristupa mrenim resursima te izdvajanja i zatite pojedinih segmenata unutar mree upotreba metoda za otkrivanje neovlatenog pristupa i radnja na informacijskom sustavu upotreba metoda za otkrivanje pogreaka u podacima i naruavanja njihova integriteta metode otkrivanja, sprjeavanja irenja i unitavanja malicioznog koda.
3.3.3. Fizike kontrole Fizike kontrole tite i osiguravaju resurse informacijskog sustava od neovlatenog fizikog pristupa, krae, fizikog oteenja ili unitenja. Fizike kontrole trebaju pruiti potporu upravljakim i logikim kontrolama i zajedniki djelovati kako bi se rizik informacijskog sustava sveo na prihvatljivu razinu. Primjeri fizikih kontrola jesu: metode fizike zatite opipljive imovine (osobnih raunala, posluitelja, mrenih ureaja, kabela, medija, graevina i slino) od neovlatenog pristupa mehanizmi nadzora okoline (videonadzor prostorija banke, osvjetljivanje okoline, detektori pokreta, senzori, alarmi i slino) biometrijske kontrole pristupa informacijskim resursima kontrola vlage, temperature, dima i slino fiziko odvajanje dijelova telekomunikacijske mree mehanizmi osiguravanja priuvnog izvora napajanja elektrinom energijom (npr. sustav za neprekinuto napajanje elektrinom energijom, generatori).
34
3.4. Klasifikacija informacija

Banka mora uvati povjerljive podatke u skladu s vaeim propisima. Informacije je potrebno klasificirati u razliite grupe prema stupnju njihove osjetljivosti (npr. jako osjetljive, osjetljive i neosjetljive) s obzirom na mogue posljedice naruavanja temeljnih naela informacijskog sustava. Osjetljiva informacija je bilo koja informacija ije razotkrivanje, privremeni ili trajni gubitak, zlouporaba ili neovlatena modifikacija mogu negativno utjecati na interese banke i klijenata te na usklaenost s vaeim propisima. Banka bi trebala odrediti grupe u koje e se informacije klasificirati, te odrediti smjernice i pravila za svrstavanje u pojedinu grupu. Na temelju toga svaku informaciju potrebno je klasificirati (svrstati u neku od definiranih grupa). Cilj klasifikacije informacija jest postizanje odgovarajueg stupnja zatite informacija pri emu treba uzeti u obzir njihovu osjetljivost. Banka bi trebala donijeti i interne akte kojima bi se definirali kriteriji i postupci te odgovornosti za provoenje klasifikacije informacija. Banka takoer mora osigurati da informacije pohranjene na razliitim medijima budu adekvatno zatiene te uspostaviti siguran proces odlaganja i unitavanja tih medija.
35
4. Unutarnja revizija
U skladu s odredbama Zakona o bankama ("Narodne novine", broj 84/2002., u nastavku teksta: ZOB), banka mora organizirati unutarnju reviziju koja e neovisno i objektivno obavljati svoje poslove te koja e svojim savjetima i preporukama pridonositi unapreivanju poslovanja banke. Jedan od zadataka unutarnje revizije jest obavljanje stalnog nadzora nad cjelokupnim poslovanjem banke kako bi se provjerilo upravlja li banka sustavno rizicima koji proizlaze iz poslovnih aktivnosti banke u skladu s naelima stabilnog poslovanja, to ukljuuje upravljanje resursima informacijske i pridruenih tehnologija. Unutarnja revizija treba obavljati i poslove revizije informacijskog sustava, iz ega proizlazi da unutarnja revizija treba biti organizirana tako da se osigura sustavno obavljanje revizije informacijskog sustava. Obavljanje revizije informacijskog sustava banke, za potrebe ovog dokumenta, nazivamo unutarnjom revizijom informacijskog sustava. Kako bi se unutarnja revizija informacijskog sustava banke provela na zadovoljavajui i djelotvoran nain, osobe koje obavljaju unutarnju reviziju informacijskog sustava trebale bi: posjedovati struna znanja i vjetine, iskustvo te razinu kvalifikacija u skladu s veliinom i sloenou informacijskog sustava banke koristiti se metodologijom za provoenje revizije informacijskog sustava temeljenom na procjeni rizika koja bi detaljno definirala kriterije, nain i postupke provoenja revizije informacijskog sustava te osigurala dosljednost i sveobuhvatnost revizije informacijskog sustava razmotriti dobre prakse upotrebe softverskih alata za provoenje revizije i kontrolu informacijskog sustava evidentirati, prikupiti i arhivirati dokumentaciju na temelju koje je sastavljeno izvjee o provedenoj reviziji imajui u vidu potrebu za adekvatnom zatitom osjetljivih informacija. Banka bi trebala kontinuirano obavljati unutarnju reviziju informacijskog sustava i definirati razdoblje (ciklus) unutar kojeg e obaviti unutarnju reviziju cjelokupnoga informacijskog sustava. Prilikom sastavljanja godinjeg programa rada te odreivanja predmeta, obuhvata i uestalosti revizije pojedinih podruja informacijskog sustava potrebno je uzeti u obzir i rukovoditi se sljedeim: obavljenom procjenom rizika informacijskog sustava banke iskustvom te dobrim praksama u reviziji informacijskih sustava raspoloivim resursima novim saznanjima o informacijskom sustavu. Na temelju godinjeg programa rada unutarnje revizije potrebno je donijeti i operativne planove rada za unutarnju reviziju informacijskog sustava. Operativni planovi rada za unutarnju reviziju informacijskog sustava trebali bi sadravati barem sljedee: ciljeve i opseg revizija popis podruja koja e biti predmetom revizija popis predmeta revizije unutar svakog podruja vremenski raspored revizija koje e se obaviti u razdoblju obuhvaenom planom
36
trajanje revizija.
Na temelju provedene revizije informacijskog sustava unutarnja revizija informacijskog sustava trebala bi sastaviti pisano izvjee o obavljenoj reviziji informacijskog sustava koje bi trebalo sadravati barem sljedee: popis revidiranih podruja popis osoba koje su sudjelovale u reviziji cilj i opseg revizije ocjenu revidiranih podruja nedostatke i slabosti revidiranih podruja nezakonitosti i nepravilnosti, ako su utvrene tijekom obavljanja revizije informacijskog sustava prijedloge, preporuke i rokove za otklanjanje utvrenih nezakonitosti, nepravilnosti, nedostataka i slabosti. Unutarnja revizija trebala bi sastaviti izvjea o radu u skladu s rokovima utvrenima operativnim planom rada. Izvjea o radu trebala bi sadravati i izvjea o obavljenim revizijama informacijskog sustava. Dobre prakse nalau da unutarnja revizija informacijskog sustava bude ukljuena u revidiranje projekata i/ili njihovih faza (primjerice razvoj aplikacija, nabava, migracija sustava, integracije sustava), kao i ostalih aktivnosti vezanih uz informacijski sustav (primjerice upravljanje informacijskim sustavom, planiranje kontinuiteta poslovanja, eksternalizacija (dijela) informacijskog sustava) koje mogu imati znatan utjecaj na funkcionalnost i sigurnost informacijskog sustava.
37
5. Sigurnost informacijskog sustava

Sigurnost je odgovornost svih upravljakih razina banke te je vrlo vana u svim fazama ivotnog ciklusa informacijskog sustava. Sigurnost informacijskog sustava obuhvaa sve aspekte povezane s definiranjem, ostvarivanjem i odravanjem temeljnih naela informacijskog sustava. Kako bi se postigla i odrala adekvatna razina sigurnosti informacijskog sustava, dobre prakse nalau rukovoenje sljedeim naelima: 1. naelom zabrane svih radnja koje nisu eksplicitno doputene na temelju dodijeljenih ovlasti 2. naelom dodjele najmanjih moguih ovlasti resursima informacijskog sustava (ukljuujui osobe, sustave i procese) koje omoguuju djelotvorno poslovanje.
38
5.1. Politika sigurnosti informacijskog sustava

Politika sigurnosti informacijskog sustava temeljni je okvir za upravljanje sigurnou informacijskog sustava banke i trebala bi odraavati opeprihvaena naela sigurnosti. Politika sigurnosti informacijskog sustava trebala bi sadravati naela i principe upravljanja sigurnou resursa informacijskog sustava te odgovornosti koje se odnose na sigurnost informacijskog sustava. Banka bi trebala donijeti politiku sigurnosti informacijskog sustava, upoznati korisnike informacijskog sustava s njom te imenovati osobu odgovornu za praenje provoenja te politike. Cilj donoenja politike sigurnosti informacijskog sustava jest osiguranje adekvatne razine sigurnosti informacijskog sustava. Politika sigurnosti informacijskog sustava trebala bi obuhvatiti podruja upravljake, logike i fizike zatite resursa informacijskog sustava u skladu s veliinom, obuhvatom i kompleksnosti informacijskog sustava. Na temelju politike sigurnosti informacijskog sustava banka bi trebala propisati i primijeniti detaljne interne akte koji se odnose na sve aspekte sigurnosti informacijskog sustava. Politiku sigurnosti informacijskog sustava potrebno je usklaivati s promjenama u informacijskom sustavu i u njegovoj okolini, u sluajevima naruavanja sigurnosti informacijskog sustava, te ovisno o rezultatima procjene rizika. Politika sigurnosti informacijskog sustava treba sadravati barem sljedee: cilj i opseg politike sigurnosti informacijskog sustava naela upravljanja sigurnou informacijskih resursa ope i posebne odgovornosti koje se odnose na sigurnost informacijskog sustava. Naela upravljanja sigurnou resursa informacijskog sustava trebala bi obuhvatiti barem sljedea podruja: upravljanje rizikom informacijskog sustava klasifikaciju informacija upravljanje sigurnou komunikacijskih i distribucijskih kanala osiguravanje kontinuiteta poslovanja banke upravljanje incidentima oporavak informacijskog sustava upravljanje priuvnom pohranom razvoj informacijskih sustava unutar banke upravljanje odnosima s pruateljima usluga i dobavljaima opreme upravljanje kontrolama pristupa resursima informacijskog sustava fiziku sigurnost upravljanje operativnim i sistemskim zapisima zatitu od malicioznog koda upravljanje imovinom informacijskog sustava upravljanje promjenama upravljanje konfiguracijama upravljanje dokumentacijom izobrazbu korisnika informacijskog sustava. Politika sigurnosti informacijskog sustava treba biti djelotvorna i primjenjiva kako bi se omoguilo ostvarivanje poslovnih ciljeva banke.
39
5.2. Upravljanje kontrolama pristupa

Kontrole pristupa omoguuju provoenje radnja nad resursima informacijskog sustava (primjerice koritenje, mijenjanje, pregled) u skladu s dodijeljenim ovlastima. Pristup se moe definirati kao svojstvo koje omoguuje obavljanje razliitih radnja na informacijskom sustavu. Kontrolama pristupa eksplicitno se omoguava, ograniava ili zabranjuje pristup resursima informacijskog sustava, i to koritenjem pojedine kontrole ili kombinacijom upravljakih, logikih i fizikih kontrola. Proces kontrole pristupa obuhvaa uvoenje niza pojedinanih kontrola pristupa. Cilj uvoenja kontrola pristupa jest sprjeavanje neovlatenog pristupa resursima informacijskog sustava. Pri implementaciji kontrola pristupa potrebno je uzeti u obzir sigurnosne zahtjeve, zahtjeve poslovnih procesa i jednostavnost koritenja za korisnike.
5.2.1. Kriteriji pristupa resursima Banka bi trebala kontrolirati pristup resursima informacijskog sustava primjenjujui, prema potrebi, neke od sljedeih kriterija: Identitet korisnika. Identitet korisnika mora biti jedinstven kako bi se mogle utvrditi ovlasti i odgovornosti svakog korisnika. Funkcija. Pristup informacijama mora biti kontroliran na temelju dodijeljenih poslova i dunosti u skladu s naelima podjele poslova i segregacije dunosti. Navedeno ukljuuje odreivanje radnja koje se mogu obavljati nad resursima informacijskog sustava (primjerice pravo itanja, pisanja, izvravanja i brisanja). Lokacija. Identifikacija i autentifikacija mogu ovisiti i o fizikoj i logikoj lokaciji osobe, procesa ili sustava koji zahtijevaju pristup (primjerice kada korisnici pristupaju s lokacije koja se nalazi unutar banke, mogu im se dopustiti vee ovlasti nego kada pristupaju putem javno dostupnih telekomunikacijskih mrea). Vrijeme. Ogranienje kojim se onemoguuje pristup u odreenom razdoblju tijekom dana ili odreenih dana u tjednu odnosno u mjesecu (primjerice koritenje nekih resursa moe biti doputeno samo tijekom radnog vremena). Transakcija. Pristup resursima informacijskog sustava moe biti ogranien ovisno o tijeku poslovnog procesa (primjerice isplatu s rauna nije mogue obaviti dok se provodi neka druga isplata ili uplata na taj raun).
5.2.2. Upravljanje korisnikim pravima Svakom resursu informacijskog sustava moe se pristupati od strane nekog drugog resursa (koji moe, ali i ne mora biti dio informacijskog sustava banke), ukljuujui i osobe. Prava pristupa koja su vea od onih koja su minimalno potrebna za obavljanje poslova, izlau informacijski sustav banke riziku naruavanja temeljnih naela informacijskog sustava. Prema tome, cilj upravljanja pravima pristupa jest identificirati pristup i ograniiti pristup pojedinom resursu na minimalnu razinu dovoljnu za djelotvorno obavljanje radnih zadataka.
40
Upravljanje korisnikim pravima (pri tome se misli na osobe, sustave i procese) sastoji se od etiriju procesa: Evidentiranje. Podrazumijeva dodavanje novih korisnika informacijskog sustava. Ovim procesom utvruje se identitet korisnika te odreuju informacije i sustavi potrebni za obavljanje radnih zadataka u skladu s opisom radnoga mjesta. Autorizacija. Podrazumijeva dodjelu prava pristupa korisnika informacijskom sustavu banke. Navedeno obuhvaa dodavanje, brisanje ili modificiranje dodijeljenih prava pristupa operativnim sustavima, aplikacijama i specifinim vrstama informacija. Postupak dodjele prava pristupa treba biti formaliziran te sva prava trebaju odobriti ovlatene osobe. Identifikacija i autentifikacija. Podrazumijeva identifikaciju korisnika i potvrdu njegova identiteta prilikom prijave i tijekom provoenja radnja na informacijskom sustavu. Nadzor. Obuhvaa praenje, izmjenu i revidiranje prava pristupa korisnika informacijskog sustava. Banka bi trebala uspostaviti djelotvoran proces upravljanja korisnikim pravima pristupa. Navedeni proces trebao bi ukljuiti sljedee kontrole: dodjeljivanje korisnicima prava pristupa koja su strogo ograniena na one kontrole koje su potrebne za obavljanje redovnih poslovnih zadataka auriranje prava pristupa (primjerice na temelju kadrovskih promjena, promjena na informacijskom sustavu i njegovu okruenju) periodino pregledavanje korisnikih prava pristupa (uestalost pregledavanja trebala bi se temeljiti na procjeni rizika).
5.2.3. Identifikacija i autentifikacija Identifikacija i autentifikacija kljune su komponente u izgradnji sigurnosti informacijskog sustava jer su osnova za mnoge vrste kontrola pristupa i utvrivanja odgovornosti korisnika (dokazivost). Utvrivanje odgovornosti korisnika zahtijeva povezivanje aktivnosti na informacijskom sustavu s tono odreenim osobama, procesima ili sustavima te je u tu svrhu potrebno da ih informacijski sustav identificira i autentificira.
5.2.3.1. Identifikacija Identifikacija je proces kojim korisnik predoava informacijskom sustavu zahtijevani identitet. Identifikacija na informacijskim sustavima najee se provodi pomou jedinstvene korisniko-identifikacijske oznake (engl. User ID). Pri upotrebi navedene oznake potrebno je obratiti posebnu pozornost na sljedee: Jedinstvenu identifikaciju. Potrebno je osigurati jedinstvenu identifikaciju svakom korisniku informacijskog sustava. U odreenim sluajevima moe se dopustiti upotreba grupnog identiteta, no to je poeljno izbjegavati jer onemoguuje dokazivost. Upravljanje jedinstvenim korisniko-identifikacijskim oznakama. Ovlasti za rad na sustavu potrebno je pratiti i aurirati. Kako bi se omoguilo praenje povijesnih aktivnosti korisnika, potrebno je procijeniti potrebu za uvanjem korisnikoidentifikacijske oznake i nakon ukidanja korisnikovih ovlasti.
41
Neaktivne jedinstvene korisniko-identifikacijske oznake. Korisnike koji su u odreenom razdoblju neaktivni na pojedinom resursu informacijskog sustava, treba analizirati i prema procjeni dezaktivirati njihove oznake i ukinuti ovlasti. Uzajamnu povezanost aktivnosti i korisnika. Informacijski sustav treba osigurati praenje identiteta svih korisnika i biti sposoban povezati aktivnosti s tono odreenim korisnicima.
5.2.3.2. Autentifikacija Autentifikacija je proces kojim se potvruje korisniki identitet koji zahtijeva pristup informacijskom sustavu. Postoje tri naina utvrivanja neospornosti korisnikog identiteta koji se mogu primjenjivati samostalno ili u kombinaciji: neto to samo korisnik zna (primjerice zaporka, PIN, kriptografski klju) neto to samo korisnik posjeduje (primjerice "token", magnetska kartica, "pametna kartica") neto to korisnik jest (primjerice biometrijske metode kao to su otisak prsta, skeniranje ronice, prepoznavanje glasa i slino). Banka bi trebala osigurati barem sljedee: Autentificiranje korisnika. Banka bi trebala zahtijevati od korisnika da potvrdi svoj identitet na informacijskom sustavu. Isto tako, banka bi u skladu s procjenom rizika trebala razmotriti i mogunost autentifikacije korisnika pomou metode samo jedne prijave (engl. single sign-on) kojom se pristupa razliitim resursima informacijskog sustava. Ogranien pristup autentifikacijskim oznakama. Autentifikacijske oznake trebaju biti adekvatno zatiene (primjerice primjenom rigoroznih kontrola pristupa i jednosmjernim kriptiranjem) kako bi se sprijeilo da neovlateni korisnici dou u posjed navedenih oznaka. Siguran prijenos autentifikacijskih oznaka. Banka bi trebala adekvatno zatititi autentifikacijske oznake prilikom njihova prijenosa javno dostupnim ili privatnim telekomunikacijskim mreama. Ograniiti broj pokuaja pristupa. Banka bi trebala ograniiti broj neuspjelih pokuaja pristupa, odnosno onemoguiti upotrebu korisniko-identifikacijske oznake nakon odreenog broja neuspjelih pokuaja pristupa resursima informacijskog sustava. Zatita autentifikacijskih oznaka prilikom unoenja. Banka bi trebala adekvatno zatititi autentifikacijske oznake od kompromitiranja prilikom unosa u informacijski sustav (primjerice skrivanje zaporka pri unosu). Upravljanje autentifikacijskim oznakama. Banka bi trebala adekvatno upravljati autentifikacijskim oznakama (primjerice definirati postupke za aktivaciju autentifikacijskih oznaka i dezaktivaciju izgubljenih i ukradenih oznaka).
42
5.2.4. Upravljanje zaporkama Zaporke su najee upotrebljavan mehanizam autentifikacije korisnika. Meutim, zbog neprimjerenih navika korisnika informacijskog sustava (primjerice dijeljenja zaporka i njihove neadekvatne pohrane te upotrebe neprimjerenih zaporka) one su i jedan od najslabijih mehanizama autentifikacije. Primjereno upravljanje zaporkama (koje ukljuuje uklanjanje poznatih ranjivosti i prevenciju uobiajenih napada) moe uvelike unaprijediti sigurnost informacijskog sustava. Napadi na zaporke odnosno pokuaji njihova otkrivanja ili zaobilaenja jedna su od najeih vrsta napada na informacijske sustave. Neke od najeih podvrsta napada na zaporke jesu: pokuaj pogaanja zaporka isprobavanjem svih kombinacija doputenih simbola (engl. dictionary attack) pokuaj pogaanja zaporka pomou specifinih informacija o osobi koja rabi tu zaporku (primjerice ime suprunika, imena djece, ime kunog ljubimca i slino) pokuaj neautorizirane autentifikacije pomou standardnih zaporka koje inicijalno definiraju proizvoai hardvera, softvera i telekomunikacijske opreme pokuaj neautorizirane autentifikacije pomou zaporka ija je povjerljivost naruena zbog neadekvatne pohrane. Ovisno o procjeni rizika, odnosno riziku razotkrivanja zaporka i negativnom uinku koji moe nastati kao posljedica tog razotkrivanja, banka bi trebala postii adekvatnu razinu zatite zaporka pomou upravljakih, logikih i fizikih kontrola. Zbog mnogobrojnih ranjivosti koje proizlaze iz neadekvatnog koritenja zaporki, te velikog broja prijetnja koje pokuavaju iskoristiti te ranjivosti, banka bi trebala propisati restriktivne postupke upravljanja zaporkama, kako bi se osjetljivost na tu vrstu napada svela na najmanju moguu mjeru. Pri upravljanju zaporkama banka bi trebala uzeti u obzir barem sljedee: sve zaporke moraju biti povjerljive; zaporke ne smiju biti pohranjene ni prikazane u itljivom (nekriptiranom) obliku izvan adekvatno osigurane okoline (primjerice u sefu); zaporke ne smije dijeliti vie korisnika kako bi se osigurala dokazivost; potrebno je definirati razdoblje nakon kojega se zaporka mora izmijeniti te onemoguiti viekratnu upotrebu iste zaporke; zaporke je potrebno izmijeniti ukoliko se pojavi i najmanja sumnja da su njihova povjerljivost ili integritet narueni; potrebno je propisati standarde kreiranja zaporka koji e biti u skladu s dobrim praksama i ogranienjima sustava za autentifikaciju te ukljuivati propisivanje: najmanje doputene duljine zaporka obavezne uporabe to ireg znakovnog skupa nemogunosti upotrebe tri ili vie uzastopnih identinih simbola u zaporci; pri prvoj upotrebi potrebno je izmijeniti prvobitne (inicijalne) i standardne zaporke, kao i ostale zaporke koje su zadali proizvoai i dobavljai informacijske opreme ili pruatelji usluga, a pomou kojih se pristupa resursima banke; mogunost autentifikacije pomou odreene zaporke potrebno je sprijeiti ako korisnik vie puta uzastopno pogrijei pri unosu te zaporke.
43
5.2.5. Mehanizmi kontrole pristupa Prilikom implementiranja kontrola pristupa banka bi trebala razmotriti upotrebu, primjerice sljedeih mehanizama: Pristupne liste (engl. Access Control Lists). Pristupne liste su evidencije korisnika (ukljuujui i grupe, sustave i procese) kojima su dane ovlasti za koritenje pojedinih resursa informacijskog sustava i poduzimanje radnja u vezi s njima. Ogranieno korisniko suelje. Pristup pojedinim resursima i funkcijama informacijskog sustava ogranien je na radnje za koje je korisnik ovlaten, primjerice upotrebom dinamikih izbornika, upotrebom prikaza podataka iz tablica baze podataka (engl. database view), upotrebom fizikog ogranienja korisnikog suelja na bankomatima i slino. Kriptografija. Kriptografske metode omoguuju primjenu sigurnijih kontrola pristupa. Da bi te metode bile djelotvorne, potrebno je uspostaviti rigorozan sustav upravljanja kriptografskim kljuevima. Vatrozidi i ostala suelja izmeu telekomunikacijskih mrea. Navedeni ureaji filtriraju promet izmeu povezanih telekomunikacijskih mrea i doputaju lokalnim korisnicima povezivanje s vanjskim mreama, dok u isto vrijeme tite informacijski sustav banke od naruavanja temeljnih naela informacijskog sustava.
5.2.6. Pristup telekomunikacijskim mreama banke Mrena sigurnost zahtijeva djelotvornu primjenu razliitih vrsta kontrola kako bi se adekvatno zatitio pristup resursima informacijskog sustava. Prema sloenosti njezine telekomunikacijske mree banka bi trebala ocijeniti i na odgovarajui nain primijeniti upravljake, logike i fizike kontrole. Dobre prakse nalau uvoenje sljedeeg: grupiranje mrenih posluitelja, aplikacija, korisnika te ostalih resursa informacijskog sustava u sigurnosne zone, primjerice podjelu u zonu nad kojom banka nema potpunu kontrolu (npr. internet), zonu vanjskih pruatelja usluga i zone razliitih grupa internih korisnika uspostavu odgovarajuih pravila pristupa unutar pojedine sigurnosne zone ili izmeu vie razliitih zona primjenu odgovarajuih upravljakih, logikih i fizikih kontrola kako bi se dosljedno udovoljilo prethodno navedenim pristupnim zahtjevima.
5.2.7. Pristup sistemskom softveru Sistemski softver obuhvaa operativne sustave i sistemske uslune programe. Banka bi trebala primjereno zatititi pristup sistemskom softveru uzimajui u obzir sljedee: ograniavanje pristupa sistemskim uslunim programima ograniavanje upotrebe i nadzor povlatenog pristupa evidentiranje i nadzor pristupa osjetljivim resursima od strane osoba, procesa ili sustava nadograivanje operativnih sustava sigurnosnim programskim ispravkama (engl. security patch)
44
zatitu pristupnih toaka (ukljuujui i ogranienje broja pristupnih toaka), putem kojih se moe pristupiti operativnom sustavu, primjenom logikih i fizikih kontrola.
5.2.8. Pristup aplikacijama U skladu s procjenom rizika u aplikacije je potrebno ugraditi mehanizme kontrole pristupa kojima se ograniava pristup osobama, procesima i sustavima. Za ostvarivanje djelotvorne kontrole pristupa aplikaciji nuna je suradnja osoba zaduenih za sigurnost, zaposlenika koji sudjeluju u razvoju i odravanju aplikacije (ukljuujui dobavljae aplikacija i pruatelje usluga odravanja) te osoba odgovornih za poslovne procese. Banka bi trebala kontrolirati pristup aplikacijama koristei, primjerice, sljedee: mehanizme autentifikacije i autorizacije koji odgovaraju procjeni rizika pojedine aplikacije nadzor prava pristupa kako bi se osiguralo da su prava korisnika na razini minimalno potrebnih za obavljanje poslovnih zadataka pristup aplikaciji samo u odreenom razdoblju (primjerice samo u radno vrijeme) evidentiranje pristupa i sigurnosnih dogaaja (primjerice praenjem sistemskih i operativnih zapisa) softver koji omoguava brzu analizu aktivnosti korisnika.
5.2.9. Udaljeni pristup Banka bi trebala biti svjesna mogunosti koje prua udaljeni pristup sustavu i ranjivosti koje iz toga proizlaze, te bi prema tome trebala definirati naine primjene i ogranienja udaljenog pristupa. Svrha je navedenog svoenje na najmanju moguu razinu izloenosti banke teti koja moe proizii iz neovlatenog koritenja informacijskih resursa banke. Banka bi trebala zatititi pristup svojim sustavima s udaljene lokacije uzimajui u obzir sljedee: internim je aktima potrebno onemoguiti udaljeni pristup osim ako za to postoje opravdane poslovne potrebe potrebno je strogo kontrolirati pristup pomou formalnog sustava odobrenja i revizije dodijeljenih prava za udaljeni pristup; potrebno je uvesti rigorozne kontrole nad konfiguracijama resursa informacijskog sustava koji omoguuju udaljeni pristup kako bi se banka zatitila od mogue zloupotrebe udaljenog pristupa (primjer takve kontrole je automatski povratni poziv); primjenu evidentiranja i nadzora svih radnja provedenih koritenjem udaljenog pristupa (primjerice praenjem sistemskih i operativnih zapisa); navedeno ukljuuje podatke kao to su datum, vrijeme, korisnik, lokacija korisnika, trajanje i svrha svih udaljenih pristupa; u svrhu zatite komunikacija potrebno je primijeniti "jaku" autentifikaciju (primjerice kombinaciju dvaju naina utvrivanja neospornosti korisnikog identiteta) i enkripciju (primjerice VPN).
45
5.2.10. Povlateni pristup Povlateni pristup omoguuje zaobilaenje sistemskih i aplikativnih kontrola informacijskog sustava. Stoga je posebnu pozornost potrebno posvetiti kontroli osoba, procesa i sustava s pravom povlatenog pristupa komponentama informacijskoga sustava banke (primjerice korisnika s administratorskim ovlastima na operativnim sustavima, aplikacijama, bazama podataka i mrenim resursima). Dobre prakse kontrole povlatenog pristupa ukljuuju: identificiranje svih osoba, procesa i sustava s povlatenim pravima pristupa koritenje povlatenim pristupom iskljuivo za radnje koje se ne mogu obaviti pomou pristupa s manjim pravima uspostavu formalnog sustava dodjele prava povlatenog pristupa periodino revidiranje postupka dodjeljivanja te dodijeljenih prava povlatenog pristupa evidentiranje i revidiranje aktivnosti koje se provode putem povlatenog pristupa (primjerice pregledom sistemskih i operativnih zapisa) rigoroznu zatitu identifikacijskih i autentifikacijskih oznaka koje se rabe za povlateni pristup na informacijskom sustavu definiranje postupaka koji e u izvanrednim situacijama ovlatenim osobama omoguiti povlateni pristup informacijskom sustavu (primjerice saznavanje identifikacijskih i autentifikacijskih oznaka korisnika s administratorskim ovlastima pohranjenih u sefu u itljivom obliku) izbjegavanje dijeljenja istih identifikacijskih i autentifikacijskih oznaka s pravima povlatenog pristupa izmeu vie korisnika.
46
5.3. Kriptografija
Banka bi trebala na osnovi obavljene procjene rizika odrediti adekvatne kriptografske metode ija e primjena smanjiti rizik od naruavanja temeljnih naela informacijskog sustava. Osnovne komponente svake kriptografske metode jesu kriptografski algoritam (opisuje kako se provodi transformacija) te jedan ili vie kriptografskih kljueva (podatak pomou kojeg se obavlja transformacija). Kriptografske metode omoguuju zatitu podataka i kada oni vie nisu pod kontrolom njihova vlasnika. Kriptografske metode rabe se kao vrsta logikih kontrola, te se njima dodatno osigurava zatita informacija i smanjuje rizik od naruavanja temeljnih naela informacijskog sustava. Kriptografija se najee upotrebljava: za enkripciju (enkripcija ili ifriranje je proces u kojem se podaci transformiraju u neitljivu formu iz koje poetne podatke mogu dobiti samo osobe koje posjeduju kriptografski klju pomou kojega se obavlja dekripcija; enkripcija osigurava povjerljivost podataka prilikom njihovog prijenosa ili pohrane) za elektroniko potpisivanje (elektroniki potpis moe se dodati bilo kojem podatku pohranjenom u elektronikom obliku; njime se, pomou kriptografskih mehanizama, omoguuje potvrivanje temeljnih naela informacijskog sustava) za ouvanje integriteta podataka za utvrivanje autentinosti korisnika. Posebnu pozornost potrebno je posvetiti upravljanju kriptografskim kljuevima (ukljuujui, primjerice, postupke njihova generiranja, pohrane, razmjene, upotrebe, uklanjanja iz upotrebe i unitavanja). Izgubljeni ili oteeni dekripcijski kljuevi mogu onemoguiti ovlatenim osobama pravodobni pristup podacima. Kriptografske metode mogu se implementirati pomou softverskih ili hardverskih resursa te njihovom kombinacijom. Dobre prakse nalau primjenu provjerenih kriptografskih algoritama i implementacija koje su bile predmet detaljnog i opsenog testiranja.
47
5.4. Fizika sigurnost

Fizika sigurnost obuhvaa kontrole koje se provode radi zatite resursa informacijskog sustava od neovlatenog fizikog pristupa, krae, fizikog oteenja ili unitenja. Temeljna naela informacijskog sustava mogu biti naruena izmeu ostalog zbog neovlatenog fizikog pristupa i oteenja ili unitenja imovine informacijskog sustava. Rizici povezani s fizikom sigurnou mogu se smanjiti uvoenjem sigurnosnih zona. Sigurnosne zone (u nastavku teksta: zone) fiziki su prostori s razliitim zahtjevima fizike sigurnosti. Sigurnosni zahtjevi za svaku zonu proizlaze iz vrste i osjetljivosti resursa informacijskog sustava koji su smjeteni u zoni, te se trebaju definirati u skladu s procjenom rizika, pri emu valja uzeti u obzir razliite vrste prijetnja (prirodne, uzrokovane ljudskim djelovanjem, sluajne ili namjerne) i ranjivosti te posljedice neeljenih dogaaja. Banka bi trebala definirati zone i primijeniti odgovarajue upravljake, logike i fizike kontrole u svakoj od definiranih zona. Navedene se kontrole, izmeu ostalog, primjenjuju radi zatite prostorija s resursima informacijskog sustava, samih resursa, kao i sustava koji su podrka funkcioniranju informacijskog sustava (primjerice sustava napajanja elektrinom energijom, sustava za grijanje i klimatizaciju i slino). Banka bi trebala uzeti u obzir sljedee imbenike koji mogu utjecati na fiziku sigurnost: Kontrole fizikog pristupa. Kontrole fizikog pristupa ograniavaju ulaske i naputanje prostorija u kojima su smjeteni resursi informacijskog sustava banke kao i unoenje te iznoenje opreme i medija. Primjeri su ovakvih prostorija raunalni centri, prostorije s posluiteljima, prostorije s telekomunikacijskom opremom i slino. Zatita od poara. Poar ima potencijal da djelomino ili potpuno uniti resurse informacijskog sustava (ukljuujui i rizik za ljudske ivote). Isto tako, dim, nagrizajui plinovi i vlaga, koji se oslobaaju za vrijeme poara, mogu nainiti tetu i na ostalim dijelovima sustava irei se kroz graevinski objekt. Sustavi za podrku. Banka bi trebala osigurati ispravan rad sustava za podrku. Zastoji u radu sustava za podrku (primjerice sustava za odravanje stabilnog i neprekinutog napajanja elektrinom energijom, sustava za grijanje, sustava za klimatizaciju i slino) mogu izazivati prekide u radu informacijskog sustava i njegovo oteenje. Dobre prakse nalau provoenje kontrole svojstava zraka (primjerice temperature, vlanosti, istoe i koncentracije oneienosti zraka) u prostoru s resursima informacijskog sustava kako bi se udovoljilo zahtjevima osoblja i informacijskog sustava. Konstrukcija objekta. Potrebno je imati u vidu da graevinski objekt moe biti podvrgnut veem optereenju nego to je u stanju izdrati. Konstrukcija objekta moe biti oteena, oslabljena ili unitena zbog potresa, raznih dodatnih optereenja, eksplozija ili poara. Posljedica unitenja graevinskog objekta moe biti fiziko oteenje ili unitenje (dijela) informacijskog sustava. Zatita od utjecaja vode. Prodor vode moe biti razoran za informacijski sustav. Potrebno je razmotriti posljedice koje prodor vode moe izazvati i posjedovati tone informacije o mrei vodovodnih instalacija te instalacija rashladnih ureaja koje mogu ugroziti resurse informacijskog sustava. Banka bi trebala, u skladu s procjenom rizika, poduzeti adekvatne mjere za smanjenje rizika kao to su ugradnja "dvostrukog poda", premjetanje resursa informacijskog sustava te vodovodnih instalacija i slino.
48
5.5. Upravljanje operativnim i sistemskim zapisima

Operativni i sistemski zapisi omoguuju uvid u aktivnosti resursa informacijskog sustava (primjerice operativnih sustava, vatrozida, usmjernika, sustava za otkrivanje neovlatenog pristupa i radnja na informacijskom sustavu, aplikacijskih sustava, procesa, osoba). U kombinaciji s odgovarajuim internim aktima, procedurama i alatima, operativni i sistemski zapisi (u nastavku teksta: zapisi) omoguuju postizanje ciljeva povezanih sa sigurnou i funkcionalnou, ukljuujui rekonstrukciju dogaaja, osobnu odgovornost, otkrivanje neovlatenog pristupa i radnja te identifikaciju problema. Zapisi se, izmeu ostalog, upotrebljavaju za sljedee: Rekonstrukciju dogaaja. Banka moe upotrebljavati zapise za rekonstrukciju izvrenih radnja (primjerice kao pomo u naknadnoj istrazi kojom se utvruje kako, kada i zato su redovne operacije prekinute te tko je, kako i kada obavio odreenu radnju). Osobna odgovornost. Zapisi slue za poticanje savjesnog koritenja resursa jer korisnici znaju da se njihove radnje mogu naknadno analizirati i jedinstveno pratiti do izvora. Otkrivanje neovlatenog pristupa i radnja na sustavu. Zapisi se mogu rabiti kao pomo u otkrivanju neovlatenog pristupa i radnja na sustavu ukoliko je sustav za otkrivanje takvih aktivnosti pravilno konfiguriran, odnosno ako biljei odgovarajue informacije. Navedene aktivnosti mogu biti otkrivene u realnom vremenu analizom zapisa u trenutku kreiranja ili naknadno. Identifikacija problema. Zapisi mogu takoer pomoi u identificiranju ostalih sigurnosnih i funkcionalnih problema na informacijskom sustavu u realnom vremenu. Zapisi trebaju sadravati dovoljnu koliinu informacija za utvrivanje pojave dogaaja i njihova uzroka. Obuhvat i sadraj zapisa potrebno je pomno definirati, u skladu s procjenom rizika, kako bi se uravnoteila potreba izmeu sigurnosti s jedne strane, te uinkovitosti i trokova s druge strane. Posebnu pozornost treba posvetiti ouvanju integriteta zapisa, da bi se osigurala dokazivost i neporecivost dogaaja. Isto tako, potrebno je osigurati i povjerljivost zapisa u skladu s klasifikacijom informacija. Openito, zapis o dogaaju treba pruiti informaciju: o vrsti dogaaja o vremenu kada se dogaaj dogodio o identifikaciji osoba, sustava ili procesa povezanih s dogaajem o programu ili naredbi koja je upotrijebljena za pokretanje dogaaja.
5.5.1. Sigurnost operativnih i sistemskih zapisa U svrhu zatite integriteta, dokazivosti i neporecivosti informacijskog sustava operativni i sistemski zapisi moraju biti adekvatno zatieni od neautoriziranog pristupa, izmjena i brisanja, pri emu treba imati u vidu barem sljedee: povjerljivost i integritet zapisa moraju biti adekvatno zatieni; potrebno je razdvojiti dunosti osoba koje administriraju kontrole pristupa i osoba zaduenih za sigurnost od osoba koje administriraju zapise;
49
pristup zapisima putem javno dostupnih telekomunikacijskih mrea treba biti strogo kontroliran.
5.5.2. Praenje operativnih i sistemskih zapisa Osobe odgovorne za praenje zapisa trebaju redovito pratiti zapise u skladu sa svojim organizacijskim zaduenjima i ovlastima. Prilikom praenja zapisa potrebno je obratiti pozornost na sljedee: Prepoznati uobiajene aktivnosti. Osobe odgovorne za praenje zapisa trebaju znati koje su aktivnosti uobiajene kako bi mogle uspjeno uoiti neuobiajene aktivnosti. Omoguiti djelotvorno pretraivanje zapisa. Praenje zapisa moe se olakati pregledom po parametrima kao to su: korisnika, terminalska i aplikativna identifikacija, datum i vrijeme ili bilo koji drugi grupni parametar. Saznanja o postojeim problemima i ogranienjima. Administratori na razini sustava ili aplikacija trebali bi pregledavati zapise uzimajui u obzir poznate probleme sustava ili aplikacija, poznata krenja postojeih zahtjeva od strane korisnika i slino. Razviti smjernice za praenje zapisa. Osobe odgovorne za aplikacije, informacije, obradu podataka i sigurnost te administratori informacijskog sustava trebaju na temelju procjene rizika odrediti opseg i uestalost pregleda zapisa. Automatizirani alati. Banka bi trebala razmotriti primjenu alata koji pomau u izdvajanju korisnih informacija iz velike koliine podataka koje sadre zapisi (primjerice u prepoznavanju neovlatenih i neuobiajenih radnja pomou poznatih uzoraka).
50
5.6. Zatita od malicioznog koda

Maliciozni kod je bilo koji oblik programskog koda koji djeluje neoekivano i na potencijalno tetan nain. Uobiajene su vrste malicioznog koda virusi, crvi i "trojanski konji", a njihovo djelovanje moe imati samostalan uinak ili kombinirani, ime se postie vea teta. Maliciozni kod moe imati mogunost repliciranja i irenja na druge resurse informacijskog sustava. Nadalje, maliciozni kod moe ugroziti povjerljivost, integritet i raspoloivost resursa informacijskog sustava mijenjajui i briui podatke, aljui podatke izvan informacijskog sustava, uklanjajui dokaze koji se mogu iskoristiti za potrebe forenzike ili stvarajui skrivene ranjivosti koje mogu olakati neovlateni pristup i radnje na informacijskom sustavu.
Zatitne mjere i kontrole Zatitne mjere i kontrole koje se primjenjuju radi smanjenja rizika od naruavanja ili gubitka temeljnih naela informacijskog sustava zbog utjecaja malicioznog koda, podrazumijevaju slojevito oblikovanje sigurnosne infrastrukture to, izmeu ostalog, ukljuuje primjenu adekvatne tehnologije, internih akata i edukaciju zaposlenika. Kontrole koje bi banka trebala primijeniti kako bi smanjila prije navedene rizike, izmeu ostalog, ukljuuju proizvode i sustave za otkrivanje i unitavanje malicioznog koda kao i ostale sustave za ograniavanje i otkrivanje neuobiajenih ili neovlatenih radnja te za nadziranje i upravljanje radnjama koje su doputene (primjerice vatrozid, IDS). Budui da se svakodnevno pojavljuju novi primjeri malicioznog koda i neovlatenih pristupa i radnja, banka bi trebala to ee, a najmanje jednom dnevno, provjeriti aurnost svojih sustava zatite od malicioznog koda te neuobiajenih i neovlatenih radnja. Banka bi u sklopu procjene rizika trebala takoer uzeti u obzir injenicu da sustavi za otkrivanje malicioznog koda koji se temelje na prepoznavanju uzorka mogu bitno tee (potrebna je dekripcija) otkriti maliciozni kod u enkriptiranim podacima (primjerice VPN i slino). Nadalje, banka bi, zbog potencijalno sve sloenijih neovlatenih radnja i zbog toga to se autori malicioznog koda esto koriste metodama socijalnog inenjeringa, trebala implementirati ostale kontrole koje, izmeu ostalog, ukljuuju interne akte o upotrebi resursa informacijskog sustava i edukaciju korisnika informacijskog sustava o moguim prijetnjama. Banka bi trebala uzeti u obzir sljedee imbenike koji mogu utjecati na sigurnost: potrebu za redovitim pregledom resursa informacijskog sustava s obzirom na neautorizirani odnosno nedoputeni softver sprjeavanje neovlatene instalacije softvera edukaciju zaposlenika kako bi ih se upozorilo na opasnosti itanja poruka nepoznatog podrijetla, pokretanja izvrnih datoteka, socijalni inenjering i slino rukovanje medijima za pohranu i prijenos podataka naine pristupa javno dostupnim telekomunikacijskim mreama doputene aktivnosti tijekom pristupa javno dostupnim telekomunikacijskim mreama kao i tijekom upotrebe tehnologije za komunikaciju (primjerice elektronike pote i slino) uklanjanje ranjivosti sustava povezanih s poznatim malicioznim kodovima
51
adekvatno upravljanje operativnim i sistemskim zapisima koji se odnose na maliciozni kod.
52
6. Odravanje informacijskog sustava

6.1. Upravljanje imovinom informacijskog sustava
Upravljanje imovinom informacijskog sustava proces je koji obuhvaa detektiranje, evidentiranje, raspolaganje, praenje, planiranje, obnavljanje, zatitu i odlaganje imovine. Pod imovinom informacijskog sustava (u nastavku teksta: imovina) podrazumijevaju se sve vrste raunalnog softvera, hardvera, pripadajuih komponenata te informacija koje se upotrebljavaju za obavljanje poslovnih procesa u banci. Imovina, izmeu ostalog, ukljuuje sljedee: informacijsku imovinu: podatke u bazama podataka i datoteke s podacima, programski kod, sistemsku i aplikacijsku dokumentaciju, korisnike prirunike, materijal za obuku, planove, politike, strategije, standarde i procedure banke, arhivirane informacije i slino softversku imovinu: aplikacijski softver, sistemski softver, razvojne alate i uslune programe i slino hardversku imovinu: raunalnu opremu (osobna raunala, posluitelje, monitore, modeme i slino), komunikacijsku opremu (usmjernike, vatrozide, telefonske centrale, telefakse, telefonske sekretarice i slino), medije za pohranu podataka (trake, magnetne diskove, optike medije i slino) i ostalu tehniku opremu (ureaje za neprekidno napajanje strujom, klimatizacijske ureaje i slino). Nepostojanje primjerenog procesa praenja imovine moe imati negativan utjecaj na raspodjelu resursa, distribuciju softvera i hardvera i njihovo odravanje, sigurnost informacijskog sustava, na popravke imovine i slino. Isto tako, neprimjereno upravljanje imovinom moe oteati ili onemoguiti identifikaciju imovine te osoba odgovornih za imovinu i ostalih korisnika, lociranje imovine u svrhu zamjene i auriranja te djelotvorno obavljanje revizije. Nadalje, neadekvatno upravljanje imovinom poveava pravni rizik, primjerice rizik od povrede ugovora o upotrebi licenciranog softvera. Dobre prakse nalau da je u sklopu upravljanja imovinom informacijskog sustava potrebno: planirati investicije, operativne aktivnosti i pruanje podrke vezane uz imovinu alocirati imovinu tako da se osigura djelotvorno pruanje usluga uspostaviti sustav izvjetavanja o planiranim investicijama i koristima koje takve investicije donose banci imenovati osobe odgovorne za imovinu dodijeliti pripadajue odgovornosti za upravljanje i zatitu imovine. Banka bi trebala uspostaviti proces upravljanja imovinom informacijskog sustava i donijeti pripadajue interne akte koji e omoguiti adekvatno upravljanje imovinom tijekom njezina ivotnog ciklusa. ivotni je ciklus imovine razdoblje u kojem se imovina upotrebljava za obavljanje poslovnih procesa te se, primjerice, sastoji od faze nabave, implementacije, koritenja, podrke te povlaenja imovine iz upotrebe. Isto tako, banka bi u sklopu procesa upravljanja imovinom trebala definirati barem sljedee: postupke upravljanja ivotnim ciklusom imovine prava i obveze korisnika pri rukovanju imovinom postupke oznaavanja postojee i novonabavljene imovine
53
nain evidentiranja postojanja i lokacije fizikih komponenata imovine nain evidentiranja ugovora o licenciranju, distribucije softvera, odnosno procesa instalacije softverske podrke te nadogradnje postupke za izdavanje imovine zaposlenicima, nadzor nad njom i auriranje evidencija na godinjoj osnovi postupke premjetanja, zamjene, skladitenja, unitavanja i trajnog povlaenja imovine (imajui u vidu, primjerice, brisanje podataka s medija prilikom zamjene, skladitenja imovine, trajnog naputanja imovine banke i slino).
54
6.2. Upravljanje promjenama

Brzi napredak informacijske tehnologije, kao i este izmjene poslovnih zahtjeva uzrokuju potrebu za promjenom softverskih i hardverskih komponenata informacijskog sustava banke. Navedene promjene mogu rezultirati neoekivanim ponaanjem informacijskog sustava (primjerice, nekompatibilnou i nestabilnou dijelova sustava, programskim pogrekama engl. bug i slino) i negativno utjecati na njegovu sigurnost. Stoga postupke izmjene informacijskih sustava treba formalno propisati, te se ponaati oprezno i u skladu s dobrim praksama, kako bi se negativni utjecaji sveli na najmanju moguu mjeru. Osnovni je zadatak upravljanja promjenama osigurati da promjene komponenata informacijskog sustava ne narue (namjerno ili nenamjerno) sigurnost i funkcionalnost informacijskog sustava. Proces upravljanja promjenama obuhvaa postupak identifikacije poetnih inaica softverskih i hardverskih komponenata informacijskog sustava te praenje svih njihovih promjena. Upravljanje promjenama ukljuuje i upravljanje novim verzijama softvera i hardverskim komponentama, kao i upravljanje programskim ispravkama ("zakrpa", engl. patch). Potrebno je sustavno pratiti objavljivanje programskih ispravaka i izmjena, kao i novih verzija aplikativnih programa i operativnih sustava te ih, ovisno o procjeni prednosti i nedostataka implementirati na informacijskom sustavu. Posebnu pozornost treba posvetiti programskim ispravkama i novim verzijama dijelova informacijskog sustava koji ispravljaju sigurnosne propuste, te ih je na osnovi procjene rizika, a nakon testiranja, potrebno to prije integrirati u informacijski sustav. Razina detaljnosti i formalnost procesa upravljanja promjenama trebale bi ovisiti o osjetljivosti dijela informacijskog sustava koji se mijenja, odnosno trebale bi biti u skladu s opsegom i karakteristikama samih promjena. Takoer je potrebno analizirati potencijalne promjene informacijskog sustava te na temelju definiranih razloga i oekivanja od provoenja promjene odrediti i odobriti daljnje postupke i njihov opseg. Ovisno o rezultatima analize, a u skladu s opsegom i karakteristikama promjene, analiza uvoenja promjene ne mora nuno ukljuivati i provedbu procjene rizika. Proces promjene informacijskih sustava trebao bi biti propisan, standardiziran i sadravati barem sljedee: definiranje zahtjeva kojim se trai promjena analizu opravdanosti zahtjeva s izvedenim zakljucima kao i procjenu utjecaja na poslovne procese, pojedine dijelove i komponente informacijskog sustava te sigurnost sustava (primjerice planiranje kontinuiteta poslovanja, politiku sigurnosti informacijskog sustava, funkcionalnost i sigurnost aplikacija i baza podataka) planiranje testiranja i definiranje rezultata koji se trebaju ostvariti kako bi se promijenjeni sustav postavio u produkcijsku okolinu; testiranje se mora obaviti u obuhvatu koji ovisi o opsegu i karakteristikama promjene sustava i u kontroliranim uvjetima te u okolini koja je u najveoj moguoj mjeri slina produkcijskoj; prilikom testiranja treba voditi rauna o povjerljivosti informacija kreiranje nove odnosno nadopunu ve postojee dokumentacije provedbu potrebne edukacije zaposlenika planiranje i uvoenje promjena informacijskog sustava u produkcijsku okolinu; posebnu pozornost potrebno je posvetiti sigurnosti informacijskog sustava odnosno
55
mogunosti naruavanja temeljnih naela informacijskog sustava prije, tijekom ili nakon provoenja promjene dokumentiranje provedenih promjena definiranje osoba ovlatenih i odgovornih za provoenje svih navedenih postupaka arhiviranje dokumentacije nastale u procesu promjene informacijskih sustava.
Banka bi trebala posebnu pozornost posvetiti rizicima koji proizlaze iz neadekvatnog upravljanja promjenama, zato to: izostanak pravodobne promjene informacijskog sustava banke moe ostaviti neispravljenima uoene sigurnosne propuste izostanak analize ili provedba neadekvatne analize moe dovesti do uvoenja nepotrebne ili ak tetne promjene informacijskog sustava izostanak testiranja promjena informacijskog sustava moe dovesti do nekompatibilnosti dijela informacijskog sustava, nestabilnosti sustava ili poveane izloenosti banke vanjskim i unutarnjim prijetnjama; promjena informacijskog sustava bez pravodobnog auriranja dokumentacije moe dovesti do neusklaenosti izmeu stvarnog i dokumentiranog stanja sustava promjena informacijskog sustava bez pravodobne edukacije korisnika moe dovesti do njihove neadekvatne osposobljenosti za rad na informacijskom sustavu suvie formalan i detaljan proces upravljanja promjenama informacijskog sustava moe dovesti do nepravodobnog provoenja ili neprovoenja potrebnih promjena, to moe rezultirati nestabilnou sustava ili poveanom izloenou banke vanjskim i unutarnjim prijetnjama neadekvatno praenje objave novih programskih ispravaka i izmjena, te novih verzija dijelova informacijskog sustava moe ugroziti sigurnost i smanjiti funkcionalnost informacijskog sustava.
56
6.3. Upravljanje konfiguracijama

Veinu hardverskih i softverskih komponenata informacijskog sustava mogue je pomou niza postavka prilagoditi specifinim potrebama banke. Navedene postavke moraju biti na zadovoljavajui nain konfigurirane, kako bi se funkcionalnost i sigurnost sustava dovele i odrale na potrebnoj razini. Postupak upravljanja postavkama sustava nazivamo upravljanjem konfiguracijama sustava. Upravljanje konfiguracijama je proces analize, definiranja, dokumentiranja, testiranja, uvoenja u produkcijski rad, kontrole i praenja izmjena u postavkama komponenata informacijskog sustava. Upravljanje konfiguracijama treba obuhvatiti sve osjetljive postavke informacijskog sustava. Osjetljivim postavkama smatraju se sve postavke ija izmjena moe znatno utjecati na sigurnost ili funkcionalnost informacijskog sustava. Kriteriji, naini i postupci upravljanja konfiguracijama trebaju biti definirani i propisani. Procjenu rizika potrebno je provesti za nove komponente sustava, kao i prilikom promjena sustava koje imaju utjecaj na funkcionalnost postojeih postavka ili omoguuju nove postavke komponenata informacijskog sustava. Banka bi trebala na temelju obavljene procjene rizika za hardverske i softverske komponente informacijskog sustava analizirati, odrediti, testirati i dokumentirati sigurnosne i funkcionalne postavke komponenata sustava koje moraju biti primijenjene kako bi se osiguralo odravanje temeljnih naela informacijskog sustava. Izmjene propisanih postavka komponenata informacijskog sustava potrebno je dokumentirati na nain koji omoguuje praenje izmjena tijekom vremena. Sustav upravljanja konfiguracijama mora omoguiti identifikaciju svih osjetljivih postavka informacijskog sustava (koje su znaajne za djelotvorno i sigurno funkcioniranje sustava) u odreenom trenutku. Isto tako, potrebno je definirati odgovornosti za upravljanje konfiguracijama informacijskog sustava s posebnim naglaskom na zaposlenike koji su ovlateni mijenjati osjetljive postavke sustava. Pristup postavkama koje mogu utjecati na sigurnost i mogunost njihove izmjene moraju biti nadzirani i kontrolirani. Banka bi trebala posebnu pozornost posvetiti rizicima koji proizlaze iz neadekvatnog upravljanja konfiguracijama, zato to: nezadovoljavajue postavljena poetna konfiguracija hardverskih i softverskih komponenata moe dovesti do nekompatibilnosti dijela informacijskog sustava, do nestabilnosti sustava, te do poveane izloenosti banke vanjskim i unutarnjim prijetnjama; izmjene dijelova informacijskog sustava bez adekvatnog praenja postavka ili nekontrolirane promjene postavki mogu naruiti sigurnost i funkcionalnost sustava; suvie restriktivan proces upravljanja konfiguracijama moe obeshrabriti, sprijeiti ili usporiti provoenje potrebnih izmjena dijelova informacijskih sustava.
57
6.4. Dokumentacija
Banka bi trebala definirati standarde izrade, pohrane, odravanja i uvanja dokumentacije koja se odnosi na informacijski sustav banke (u nastavku teksta: dokumentacija). Dokumentacija je korisna samo ako je tona, potpuna i aurna, te je takvom treba i odravati. Stoga je potrebno definirati osobe odgovorne za dokumentaciju i njihove dunosti u odravanju tonosti, potpunosti i aurnosti dokumentacije. Banka bi trebala zaposlenicima osigurati pristup dokumentaciji koja je povezana s njihovim poslovnim potrebama. Pristup povjerljivoj dokumentaciji mora biti ogranien, kako bi svaki zaposlenik mogao pristupiti samo dokumentima za koje je ovlaten. Vanu dokumentaciju (u skladu s klasifikacijom informacija) trebalo bi pohraniti i na sigurnu udaljenu lokaciju te je periodino aurirati. Dobre prakse nalau organiziranje i voenje dokumentacije na takav nain da se za dokument mogu utvrditi odgovorne osobe, vrijeme nastanka, poetak primjene, klasifikacija te inaica. Potrebno je uspostaviti i evidenciju koja e omoguiti sveobuhvatni pregled postojee dokumentacije. Primjeri dokumentacije: interni akti vezani uz informacijski sustav (odluke, politike, procedure, upute, standardi i slino) opisi hardvera i softvera programska dokumentacija (programski kod, dijagrami i opisi naina funkcioniranja programa i slino) dijagrami i opisi poslovnih procesa korisnika dokumentacija ugovori s dobavljaima i pruateljima usluga izvjea, planovi, zapisnici, dopisi i ostala korespondencija.
58
6.5. Izobrazba
Izobrazba, odnosno edukacija, kontinuirani je proces koji se mora neprekidno odvijati kako bi se osiguralo da znanja korisnika sustava prate promjene i u informacijskom sustavu i u njegovoj okolini. Spomenute promjene ukljuuju izmjene postojeih funkcionalnosti i sigurnosnih obiljeja informacijskog sustava ili dodavanje novih kao i sve promjene izvan informacijskog sustava banke koje na njega mogu utjecati. Veina tetnih (neplaniranih i neeljenih) dogaaja na informacijskim sustavima nastaje kao posljedica ljudskog djelovanja. Od navedenih tetnih dogaaja zaposlenici poslovnog subjekta uzrokuju kudikamo vei broj nego ostale osobe. Neplanirani i neeljeni dogaaji najee nastaju kao posljedica nenamjernih radnja (pogreaka ili propusta) ili, rjee, kao posljedica namjernih radnja poinjenih s ciljem nanoenja tete informacijskom sustavu banke. Kako bi se navedeni dogaaji i njihovo tetno djelovanje sveli na prihvatljivu razinu, potrebno je primjereno educirati sve korisnike informacijskog sustava banke. Posljedica primjerene izobrazbe bit e smanjivanje broja pogreaka i propusta i ograniavanje njihova dosega te uoavanje i sprjeavanje pokuaja naruavanja temeljnih naela informacijskog sustava. Edukacija bi trebala obuhvatiti sve osobe koje se koriste informacijskim sustavom banke: informatiko osoblje banke osobe zaduene za sigurnost informacijskog sustava i unutarnju reviziju ostale zaposlenike banke koji se koriste informacijskim sustavom, i na operativnim i na upravljakim razinama osobe koje nisu zaposlenici banke, ali se koriste informacijskim sustavom banke (primjerice korisnici e-bankarstva, zaposlenici tvrtki vanjskih suradnika i slino). Izobrazba korisnika informacijskog sustava trebala bi omoguiti navedenim osobama djelotvorno obavljanje poslovnih zadataka uz istodobno svoenje neeljenih dogaaja na prihvatljivu razinu. Preciznije, ciljevi edukacije korisnika informacijskog sustava banke jesu: razviti i odravati znanja i vjetine korisnika na primjerenoj razini, kako bi oni mogli obavljati poslovne zadatke na djelotvoran i siguran nain upoznati korisnike s internim aktima (primjerice politikama, procedurama i ostalim postupcima kojih se navedeni korisnici moraju pridravati) kako bi se tono ustanovili zadaci, okviri djelovanja i osobna odgovornost svakog korisnika uspostaviti i unapreivati svijest o potrebi zatite resursa informacijskog sustava razviti i odravati znanja potrebna da bi se funkcionalnost i sigurnost informacijskog sustava zadrale na zadovoljavajuoj razini tijekom cijeloga ivotnog ciklusa informacijskog sustava. Izobrazba bi trebala biti sastavni dio strategije informacijskog sustava banke te u skladu s planiranim promjenama informacijskog sustava . Izobrazbu je potrebno unaprijed planirati te formalno identificirati i specificirati potrebne aktivnosti, nain njihova provoenja te vremenske i financijske okvire unutar kojih e se provoditi. Prilikom planiranja izobrazbe posebnu pozornost valja posvetiti potrebi usvajanja i odravanja visoko specijaliziranih tehnikih znanja ije stjecanje zahtijeva koritenje znaajnim financijskim i vremenskim resursima te veliki osobni angaman zaposlenika. Navedena visoko specijalizirana znanja
59
obino se stjeu kontinuiranom izobrazbom i strunim usavravanjem stoga ih je potrebno adekvatno planirati i provoditi. Pri tome bi banka trebala posebnu pozornost posvetiti izobrazbi unutarnje revizije, kako bi se revizija informacijskog sustava provodila na zadovoljavajui i djelotvoran nain. Ostvarivanje plana izobrazbe i njegovu provedbu potrebno je dokumentirati i pratiti. Pravilno planirana i provedena izobrazba poveat e produktivnost, iskoritenje postojeih resursa te omoguiti podizanje razine sigurnosti cjelokupnoga informacijskog sustava banke. Izobrazbu je mogue provoditi na razliite naine, od najjednostavnijih poput distribucije pisane dokumentacije do kompleksnih i dugotrajnih usavravanja. Opseg, detaljnost, trajanje i nain provoenja edukacije trebaju biti u skladu s obiljejima ciljane grupe odnosno ciljanih korisnika te s opsenosti i kompleksnosti tematike. Prilikom odreivanja obiljeja ciljanih korisnika potrebno je uzeti u obzir poslovne funkcije koje navedeni korisnici obavljaju, njihovo predznanje o predmetu edukacije te openito poznavanje funkcioniranja informacijskih sustava. Korisnike je potrebno educirati do razine detaljnosti koju zahtijevaju njihovi poslovni zadaci.
60
7. Planiranje kontinuiteta poslovanja

Planiranje kontinuiteta poslovanja treba u najveoj moguoj mjeri osigurati kontinuitet poslovanja te omoguiti banci da pomou adekvatnih mjera za oporavak u to kraem vremenu smanji ukupni uinak havarije ili drugih neeljenih i nepredvienih dogaaja (ije posljedice mogu prouzroiti prekid poslovnih procesa te u konanici i poslovanja banke) na prihvatljivu razinu. Osiguravanje kontinuiteta poslovanja postie se poduzimanjem mjera prevencije neeljenih dogaaja, ograniavanja njihova uinka i oporavka u sluaju prekida poslovnih procesa. Planiranje kontinuiteta poslovanja treba se temeljiti na analizi utjecaja na poslovanje i na procjeni rizika te omoguiti dosljedno odvijanje poslovnih procesa banke i nastavak pruanja usluga uz znaajno smanjenje rizika kojima je banka u svom poslovanju izloena (primjerice reputacijskog, financijskog, operativnog, stratekog i pravnog rizika). Zbog velike ovisnosti banke o informacijskoj tehnologiji te informacijskom sustavu koji omoguuje odvijanje poslovnih procesa, banka bi trebala pri planiranju kontinuiteta poslovanja posebnu pozornost posvetiti osiguranju raspoloivosti resursa informacijskog sustava potrebnih za odvijanje kritinih i/ili vitalnih poslovnih procesa. Djelotvornost planiranja kontinuiteta poslovanja ocjenjuje se pomou testiranja i primjene plana kontinuiteta poslovanja, plana oporavka, plana odgovora na incidente kao i uspostavom adekvatnog procesa upravljanja priuvnom pohranom. Banka bi prilikom planiranja kontinuiteta poslovanja trebala obratiti posebnu pozornost: na identificiranje kritinih i/ili vitalnih poslovnih procesa na procjenu prihvatljivog vremena neraspoloivosti pojedinih poslovnih procesa na identificiranje resursa koji su potrebni za odravanje kritinih i/ili vitalnih poslovnih procesa na procjenjivanje pojave i uinka potencijalnih incidenata, havarija te ostalih neeljenih i nepredvienih dogaaja na poslovne procese banke i njezine klijente na dodjelu odgovornosti u svezi s izradom, aktiviranjem i provedbom planova na revidiranje planova s obzirom na promjene (primjerice osoblja, vanjskog i unutarnjeg okruenja i slino) na donoenje ostalih internih akata u svezi s planiranjem kontinuiteta poslovanja na testiranje plana kontinuiteta poslovanja, plana oporavka i plana odgovora na incidente te priuvne pohrane i priuvnoga raunalnog centra na procjenu rizika ugovornih odnosa s kljunim pruateljima usluga i dobavljaima; na raspoloivost priuvnoga raunalnog centra na udaljenoj lokaciji na uspostavu standarda i procedura za komunikaciju sa svim osobama potrebnim za osiguranje kontinuiteta poslovanja komunikaciji osoba zaduenih za osiguravanje kontinuiteta poslovanja (primjerice tima za odgovore na incidente) i osoba zaduenih za odnose s javnou. Dobre prakse nalau uspostavu odbora za planiranje kontinuiteta poslovanja koji bi, izmeu ostalog, trebao imati savjetodavnu ulogu prilikom donoenja stratekih odluka te nadzirati i koordinirati aktivnosti u svezi s planiranjem kontinuiteta poslovanja. lanovi odbora za planiranje kontinuiteta poslovanja trebali bi biti predstavnici poslovnih organizacijskih jedinica, voditelj sigurnosti informacijskog sustava, unutarnja revizija, predstavnici organizacijske jedinice za informacijsku tehnologiju te lan uprave banke.
61
Neadekvatno planiranje kontinuiteta poslovanja moe prouzroiti: gubitak raspoloivosti gubitak reputacije gubitak konkurentskih prednosti gubitak podataka gubitak produktivnosti poveanje operativnih trokova povredu ugovornih odnosa povredu vaeih propisa financijski gubitak.
62
7.1. Analiza utjecaja na poslovanje

Analiza utjecaja na poslovanje (engl. Business Impact Analysis) jest proces analiziranja poslovnih procesa i resursa informacijskog sustava potrebnih za odvijanje poslovnih procesa koji obuhvaa barem sljedee: 1. identifikaciju poslovnih procesa i klasifikaciju s obzirom na njihovu kritinost i/ili vitalnost 2. identifikaciju resursa informacijskog sustava potrebnih za odvijanje poslovnih procesa, njihovih meuovisnosti te povezanosti s drugim informacijskim sustavima 3. procjenu rizika vezanih uz pojedine poslovne procese 4. odreivanje prihvatljive razine pojedinih rizika 5. odreivanje prihvatljivog vremena neraspoloivosti pojedinih poslovnih procesa, tj. vremena u kojem je potrebno obnoviti poslovni proces (engl. Recovery Time Objective - RTO) 6. odreivanje vremena (u odnosu na vrijeme poetka havarije ili drugog neeljenog i nepredvienog dogaaja) od kojeg e banka biti u stanju obnoviti podatke (engl. Recovery Point Objective - RPO) 7. utvrivanje prioriteta oporavka poslovnih procesa. Analiza utjecaja na poslovanje temelj je za planiranje kontinuiteta poslovanja i djelotvornog oporavka poslovnih procesa odnosno resursa informacijskog sustava potrebnih za odvijanje poslovnih procesa. Vrijeme i ostali resursi potrebni za provoenje analize utjecaja na poslovanje ovisit e prije svega o veliini banke i kompleksnosti poslovnih procesa i informacijskog sustava. Analiza utjecaja na poslovanje treba obuhvatiti sve poslovne procese te: identificirati potencijalni uinak neeljenog, nepredvienog (i neuobiajenog) dogaaja na poslovne procese odnosno resurse informacijskog sustava potrebne za odvijanje tih procesa razmotriti utjecaj zahtjeva vaeih propisa te potreba za izvjeivanjem Hrvatske narodne banke i ostalih nadlenih institucija na poslovne procese procijeniti najdue vrijeme neraspoloivosti pojedinih vitalnih poslovnih procesa, ciljeve i prioritete oporavka te trokove vezane uz zastoje i oporavak procijeniti i postaviti prioritete na kritine i/ili vitalne poslovne procese razmotriti utjecaj prekida poslovnih procesa na klijente (primjerice obveze banke prema klijentima, oekivanja klijenata) i reputaciju banke. Uinak neeljenog i nepredvienog dogaaja moe se promatrati kao gubitak ili naruavanje temeljnih naela informacijskog sustava. Uinak neeljenih i nepredvienih dogaaja moe se mjeriti: kvantitativno (primjerice na osnovi izgubljenih prihoda ili na osnovi trokova ponovne uspostave poslovnih procesa) kvalitativno (primjerice dogaaji s velikim, srednjim ili malim utjecajem na poslovne procese odnosno na resurse informacijskog sustava). Informacije potrebne u analizi utjecaja na poslovanje mogu se prikupiti na razliite naine (primjerice uvidom u dokumentaciju i intervjuiranjem). Proces prikupljanja informacija trebao bi biti ujednaen (primjerice potrebno je provoditi intervjuiranje pomou upitnika koji e se moi primjenjivati na sve poslovne procese i organizacijske jedinice banke). Na taj e se 63
nain omoguiti postojanost i usporedivost dobivenih informacija ijom analizom bi se trebala odrediti kritinost i/ili vitalnost poslovnih procesa banke. Prilikom provoenja analize utjecaja na poslovanje posebnu pozornost potrebno je posvetiti: identificiranju svih resursa informacijskog sustava koji su potrebni za odvijanje kritinih i/ili vitalnih poslovnih procesa identificiranju osoba odgovornih za odvijanje kritinih i/ili vitalnih poslovnih procesa utjecaju analiziranih poslovnih procesa na cjelokupno poslovanje banke odreivanju prihvatljivog vremena neraspoloivosti poslovnih procesa i resursa informacijskog sustava potrebnih za odvijanje poslovnih procesa, odnosno vremena unutar kojeg je potrebno obnoviti poslovne procese (engl. Recovery Time Objective RTO) odreivanju vremena od kojeg e banka biti u stanju obnoviti podatke (engl. Recovery Point Objective - RPO) meuovisnosti prethodno navedenog resursima potrebnim za oporavak. Analizu utjecaja na poslovanje potrebno je usklaivati s promjenama poslovnih procesa banke, njezina okruenja, informacijskog sustava i drugih okolnosti koje mogu utjecati na poslovanje banke. Budui da je analiza utjecaja na poslovanje temelj za planiranje kontinuiteta poslovanja, nedostatak ili neadekvatno provoenje analize moe rezultirati neadekvatnim planiranjem kontinuiteta poslovanja. Navedeno se oituje u nemogunosti banke da prepozna kritine i/ili vitalne poslovne procese, odredi prihvatljivo vrijeme neraspoloivosti poslovnih procesa kao i mogue trokove. Sve navedeno moe dovesti do nemogunosti uspostave kritinih i/ili vitalnih poslovnih procesa, gubitka operativne uinkovitosti, neraspoloivosti informacijskog sustava, znatnoga financijskoga gubitka te gubitka reputacije banke.
64
7.2. Plan kontinuiteta poslovanja

U okviru planiranja kontinuiteta poslovanja banka bi trebala donijeti plan kontinuiteta poslovanja. Planom kontinuiteta poslovanja trebalo bi detaljno opisati postupke koje je potrebno slijediti kako bi se oporavili kritini i/ili vitalni poslovni procesi. Prilikom izrade plana kontinuiteta poslovanja banka bi trebala uzeti u obzir sve vrste dogaaja koji mogu negativno utjecati na poslovne procese i resurse informacijskog sustava potrebne za odvijanje poslovnih procesa. Svrha plana kontinuiteta poslovanja jest: osigurati ponovnu uspostavu kritinih i/ili vitalnih poslovnih procesa u zahtijevanom vremenu ograniiti i smanjiti gubitke koji mogu nastati kao posljedica prekida poslovnih procesa. Plan kontinuiteta poslovanja trebao bi: biti u pisanom obliku temeljiti se na analizi utjecaja na poslovanje i procjeni rizika precizno definirati uvjete pod kojima se aktivira te odgovornosti za njegovu aktivaciju i provedbu biti specifian s obzirom na uvjete u kojima se plan treba izvriti biti specifian s obzirom na hitne postupke u sluaju prekida poslovnih procesa uzeti u obzir resurse potrebne za obnavljanje poslovnih procesa biti dovoljno prilagodljiv kako bi se mogao primijeniti u nepredvienim situacijama biti usredotoen na odravanje kontinuiteta poslovnih procesa, a ne na istraivanje uzroka incidenta biti djelotvoran u smanjivanju tetnog uinka na poslovne procese i financijskog gubitka. Plan kontinuiteta poslovanja potrebno je usklaivati s promjenama poslovnih procesa banke, njezina okruenja, informacijskog sustava i drugih okolnosti koje mogu utjecati na poslovanje banke. Nadalje, plan kontinuiteta poslovanja potrebno je periodino testirati kako bi bio efikasan i usklaen s navedenim promjenama.
65
7.3. Plan oporavka

Zastoji i razliiti poremeaji u radu informacijskog sustava mogu znaajno ugroziti poslovanje banke zbog nemogunosti odvijanja kritinih i/ili vitalnih poslovnih procesa. Prilikom planiranja oporavka informacijskog sustava banka bi trebala uzeti u obzir mogue negativne uinke na resurse informacijskog sustava u sluaju razliitih havarija te ostalih neeljenih i nepredvienih dogaaja. Navedeni negativni uinci mogu nastati kao posljedica ostvarenja prijetnja koje mogu biti prirodne ili uzrokovane ljudskim djelovanjem (sluajno ili namjerno). U sklopu planiranja oporavka u sluaju havarije te ostalih neeljenih i nepredvienih dogaaja banka bi trebala donijeti plan oporavka kojem je cilj osigurati raspoloivost resursa informacijskog sustava potrebnih za odvijanje kritinih i/ili vitalnih poslovnih procesa u zahtijevanom vremenu. Plan oporavka je skup procedura koje obuhvaaju postupke hitnog odgovora na neeljeni dogaaj i oporavka resursa informacijskog sustava. Banka bi trebala biti svjesna da su vrijeme i ostali resursi potrebni za provoenje analize utjecaja na poslovanje, procjenu rizika, izradu plana oporavka te izradu priuvnih kopija neusporedivo manji od resursa koji bi bili potrebni kad navedeno ne bi bilo napravljeno, a kad bi dolo do havarije ili nekog drugog neeljenog i nepredvienog dogaaja. Gubitak funkcionalnosti glavnog i/ili priuvnog raunalnog centra moe usporiti ili u potpunosti onemoguiti odvijanje poslovnih procesa banke te uzrokovati znaajan financijski gubitak, ugroziti konkurentski poloaj, utjecati na reputaciju banke i prouzroiti znatne povrede vaeih propisa. Plan oporavka, izmeu ostalog, trebao bi: imati jasno definirane postupke oporavka ovisno o vrsti dogaaja i njegovu uinku na resurse informacijskog sustava, ukljuujui postupke prelaska na priuvnu lokaciju imati definirane prioritete u oporavku resursa informacijskog sustava potrebnih za odvijanje kritinih i/ili vitalnih poslovnih procesa definirati postupke evakuacije definirati odgovornosti i ovlasti osoba zaduenih za oporavak imati jasno definirane postupke vezane uz ugovorni odnos s pruateljima usluga, a koji se odnose na oporavak. Nadalje, plan oporavka trebao bi osigurati sljedee: ubrzati potrebno vrijeme reakcije skratiti vrijeme oporavka (primjerice definiranjem rutinskih procedura) pomoi u donoenju odluka u kriznim situacijama jamiti pouzdanost priuvnih sustava. Najvei prioritet pri oporavku u sluaju havarije te ostalih neeljenih i nepredvienih dogaaja ima sigurnost ljudi. Banka bi trebala osigurati da plan oporavka bude cjelovit, provediv, auran, testiran, dokumentiran te trokovno opravdan. Budui da je planiranje oporavka u sluaju havarije te ostalih neeljenih i nepredvienih dogaaja iznimno sloen i zahtjevan proces, dobre prakse nalau osnivanje odbora za planiranje oporavka.
66
7.4. Upravljanje incidentima

Incident je neplanirani i neeljeni dogaaj ija je posljedica povreda (ili koji neposredno prijeti povredom) vaeih propisa RH, politike sigurnosti informacijskog sustava, ostalih internih akata banke vezanih uz informacijsku sigurnost kao i naruavanje temeljnih naela informacijskog sustava, prihvaenih praksi vezanih uz informacijsku sigurnost te funkcionalnosti informacijskog sustava. Upravljanje incidentima je sastavni dio planiranja kontinuiteta poslovanja jer mu je cilj omoguavanje brzog i uinkovitog odgovora u sluaju naruavanja sigurnosti i funkcionalnosti resursa informacijskog sustava koji podravaju odvijanje poslovnih procesa. Kako bi banka mogla djelotvorno i pravodobno reagirati u sluajevima naruavanja funkcionalnosti i sigurnosti dijela ili cijeloga informacijskog sustava, potrebno je planirati postupke u sluaju incidenata, to ukljuuje i izradu plana odgovora na incidente. Cilj planiranja odgovora na incidente jest smanjivanje rizika od naruavanja sigurnosti i funkcionalnosti informacijskog sustava u incidentnim situacijama te pruanje praktinih smjernica za djelotvorno postupanje kad se dogode incidenti. Adekvatnim planiranjem odgovora na incidente poveava se sposobnost banke da uspjeno i brzo odgovori na incidente, da ogranii i ispravi nastale tetne uinke te da smanji tetne posljedice buduih incidenata. Pretpostavka je za uspjeno planiranje odgovora na incidente dobro poznavanje okruenja informacijskog sustava i samog sustava, to se odnosi na poznavanje i praenje potencijalnih prijetnja, s jedne strane, i poznavanja ranjivosti informacijskog sustava s druge strane. S obzirom na postupke koji se provode prilikom planiranja odgovora na incidente kao i na postupke u kriznim situacijama, upravljanje incidentima moe se podijeliti u osnovne faze: 1. Priprema. Faza pripreme ukljuuje: preventivne metode sprjeavanja incidenata podrku rukovodstva odreivanje osoba zaduenih za odgovor na incidente te definiranje njihovih ovlasti, odgovornosti i djelokruga rada planiranje komunikacije u hitnim sluajevima organizaciju sustava izvjeivanja izobrazbu zaposlenika u vezi s prepoznavanjem incidenata izobrazbu osoba zaduenih za odgovor na incidente donoenje smjernica za suradnju meu razliitim organizacijskim jedinicama definiranje odgovornosti korisnika informacijskog sustava u svezi s incidentima uspostavljanje odnosa s nadlenim institucijama kao i drugim timovima za odgovor na incidente. 2. Identifikacija. Faza identifikacije ukljuuje identifikaciju incidenta. 3. Ograniavanje. Faza ograniavanja ukljuuje provoenje potrebnih radnja od strane osoba zaduenih za odgovor na incidente (primjerice ispitivanje situacije, izbjegavanje neovlateno promijenjenog koda, izradu priuvne pohrane, procjenu rizika od nastavka rada kompromitiranog dijela informacijskog sustava, suradnju s osobama odgovornim za kompromitirani dio informacijskog sustava, promjenu zaporka i slino).
67
4. Uklanjanje. Faza uklanjanja ukljuuje: odreivanje uzroka i znaajka incidenta poboljanje sigurnosnih postavka informacijskog sustava provoenje analize ranjivosti uklanjanje uzroka incidenta lociranje aurnih priuvnih kopija koje su napravljene prije nego to je naruena funkcionalnost i sigurnost informacijskog sustava. 5. Oporavak. Faza oporavka ukljuuje ponovnu uspostavu kompromitiranih dijelova informacijskog sustava te procjenu stanja i nadzor poslovnih procesa. 6. Izvjeivanje. Faza izvjeivanja ukljuuje: izvjetavanje o svim fazama upravljanja incidentom te izradu izvjea o incidentu izradu preporuka radi breg prepoznavanja ili spreavanja ponavljanja incidenta. Upravljanje incidentima obuhvaa i odreivanje radnja za obranu od specifinih napada kao to su maliciozni kod, neovlateno analiziranje mree, napad uskraivanjem usluge (engl. Denial of Service), neprimjereno koritenje sustavom, pijunaa, prijevare, neautorizirani pristup i slino. Nadalje, dobre prakse upuuju na potrebu praenja statistika raznih prijetnja (ukljuujui razliite tipove napada) i ranjivosti sustava. Nemogunost pravodobnog odgovora na incidente izlae banku znaajnom operativnom, pravnom, reputacijskom i financijskom riziku. Banka bi trebala donijeti plan odgovora na incidente. Plan odgovora na incidente nastaje dokumentiranjem procesa planiranja odgovora na incidente, a temelji se na procjeni rizika informacijskog sustava. Plan odgovora na incidente trebao bi podrati sve faze upravljanja incidentima pri emu bi posebno valjalo istaknuti: definiranje incidenata te njihovo rangiranje definiranje procedura za postupanje u sluaju incidenata odreivanje postupaka izvjeivanja uprave banke, ostalih odgovornih osoba kao i nadlenih institucija ovisno o uincima sigurnosnog incidenta (primjerice izvjeivanje Hrvatske narodne banke, Ministarstva unutarnjih poslova i slino) odreivanje osoba zaduenih za odgovore na incidente te definiranje njihova djelokruga rada, ovlasti i odgovornosti izobrazbu osoba zaduenih za odgovore na incidente. Budui da velik broj incidenata ima karakteristike sigurnosnih incidenata pa njihovo rjeavanje zahtijeva brzi odgovor te primjenu specijalistikih znanja i multidisciplinarni pristup, dobre prakse nalau osnivanje operativnog ekspertnog tima koji e odgovarati na incidente. Osobe zaduene za odgovor na incidente odnosno tim za odgovor na incidente (engl. incident response team) treba biti u svako vrijeme dostupan svim stranama koje sumnjaju u pojavu ili su primijetile incident. Postupci lanova tima za odgovor na incidente obuhvaaju: prikupljanje i analizu informacija o incidentu odreivanje uinka incidenta poduzimanje radnja potrebnih za ograniavanje i smanjivanje nastale tete poduzimanje radnja za oporavak kompromitiranih poslovnih procesa.
68
Dobre prakse nalau usku suradnju tima za odgovor na incidente i pravnika kako bi se rijeila pravna pitanja koja se mogu pojaviti kao posljedica incidenta (primjerice odgovornost banke kada je s njezina sustava koji je kompromitiran izvren napad na sustav neke druge institucije, utvrivanje odgovornosti za nastalu tetu te odgovornost banke za izvjeivanje nadlenih institucija u sluaju incidenata).
69
7.5. Upravljanje priuvnom pohranom

Proces upravljanja priuvnom pohranom obuhvaa postupke izrade, pohrane, testiranja i restauracije podataka s priuvnih kopija. Priuvne kopije moraju sadravati sve podatke (poslovne podatke, dokumentaciju, aplikativni i sistemski softver i slino) koji su potrebni za ponovno uspostavljanje poslovnih procesa koje podrava informacijski sustav banke. Izrada priuvnih kopija podataka koji se nalaze u informacijskom sustavu zadatak je s visokim prioritetom u procesu upravljanja informacijskim sustavom. Upravljanje priuvnom pohranom potrebno je uspostaviti u skladu s klasifikacijom informacija, analizom utjecaja na poslovanje i procjenom rizika, kako bi se osigurala temeljna naela informacijskog sustava. Banka bi trebala osigurati postojanje aurnih priuvnih kopija kao i provjerenih i testiranih metoda restauriranja podataka, odnosno ponovnog uspostavljanja poslovnih procesa kako bi bio mogu uspjean oporavak u sluaju incidenata, havarija te ostalih neeljenih i nepredvienih dogaaja. Banka bi trebala donijeti interne akte kojima se definiraju kriteriji, naini i postupci upravljanja priuvnom pohranom kao to su kategorizacija, uestalost izrade, vrsta, rukovanje, pohrana, restauracija i uvanje priuvnih kopija. Isto tako, potrebno je definirati i ovlasti i odgovornosti za upravljanje priuvnom pohranom. Priuvne kopije omoguuju oporavak informacijskog sustava u sluajevima gubitka podataka povezanih s dogaajima kao to su: sigurnosni incidenti brisanje podataka zbog sluajnih ili namjernih dogaaja neoekivani prekidi u radu informacijskog sustava havarije ostali neeljeni i nepredvieni dogaaji. Uobiajene dobre prakse pri uspostavljanju sustava upravljanja priuvnom pohranom ukljuuju, izmeu ostalog, sljedee: odreivanje uestalosti izrade priuvnih kopija s obzirom na rizik i klasifikaciju informacija te u skladu s time sastavljanje plana izrade priuvnih kopija izradu, odravanje i pregled evidencije o priuvnim kopijama obiljeavanje medija na kojima su pohranjeni podaci, to ukljuuje informacije kao to su sadraj, datum izrade, vrsta kopije, sistemsko okruenje, razina osjetljivosti te ostale informacije izradu priuvnih kopija sistemskih datoteka (primjerice operativnih sustava, pogonskih programa za hardver i slino) adekvatno upravljanje fizikom sigurnou priuvnih kopija verificiranje podataka na priuvnim kopijama kako bi se omoguila uspjena restauracija podataka periodino restauriranje podataka na testnu okolinu i/ili provjeru pomou odgovarajuega softverskog alata kako bi se potvrdilo da su priuvne kopije pohranjene na ispravan nain, da nije naruen integritet podataka te da je podatke mogue restaurirati
70
periodino revidiranje procesa izrade i pohrane priuvnih kopija redovito pohranjivanje priuvnih kopija na udaljenu sigurnu lokaciju uporabu kriptografskih metoda redovito zamjenjivanje i odlaganje medija na kojima se pohranjuju podaci osiguranje raspoloivosti priuvnoga raunalnog centra na udaljenoj lokaciji. Priuvni raunalni centar, ovisno o procjeni rizika, moe imati razliitu razinu opremljenosti: od redundantnog, koji je opremljen jednako kao i glavni raunalni centar, do centra koji ima samo adekvatni prostor i instalacije (energetsku i telekomunikacijsku mreu te ostale potrebne instalacije). Posebnu pozornost potrebno je posvetiti telekomunikacijskoj povezanosti priuvnog centra i ugovornim odnosima banke s pruateljima usluga i dobavljaima opreme.
71
8. Razvoj sustava i eksternalizacija

8.1. Razvoj informacijskih sustava unutar banke
Razvoj informacijskih sustava unutar banke (engl. in-house development) sloen je proces, koji je potrebno precizno i detaljno definirati te standardizirati kako bi se rizici razvoja sveli na najmanju moguu mjeru. Banka bi trebala donijeti interne akte koji propisuju postupak razvoja informacijskih sustava i koji e se primjenjivati na sve razvojne projekte (u nastavku teksta: projekte), neovisno o karakteristikama samih projekata. Navedeni akti trebali bi obuhvatiti barem sljedea podruja: planiranje i formalnu organizaciju projekta razvoja informacijskih sustava programski razvoj i isporuku informacijskih sustava odravanje informacijskih sustava. Interni akti o razvoju informacijskih sustava trebali bi za svako od navedenih podruja propisati postupke odobravanja, pregleda, provoenja i dokumentiranja vanijih aktivnosti. Pri razvoju informacijskih sustava potrebno je uvijek imati u vidu sigurnost cjelokupnog sustava. Prilikom provedbe opsenijih projekata razvoja informacijskih sustava obino se propisuju i posebni standardi koji se primjenjuju na taj projekt. Navedeni posebni standardi trebali bi biti u skladu s internim aktima banke. Projekti koji se mogu promatrati kao izmjene ve postojeih sustava moraju biti u skladu s postupcima definiranim u poglavlju "Upravljanje promjenama".
8.1.1. Planiranje i formalna organizacija projekta razvoja informacijskih sustava Planiranje projekta je kritino razdoblje ivotnog ciklusa informacijskog sustava. Propusti u procesu planiranja esto se manifestiraju kao pomicanje rokova, poveanje trokova, neadekvatno ispunjavanje ciljeva ili ak odustajanje od projekta. Stoga je potrebno definirati sve parametre koji se moraju analizirati i dokumentirati u ovom procesu. Prije zapoinjanja projekta odgovorne osobe u banci trebale bi izraditi formalni plan koji e definirati standarde i postupke koji e se primjenjivati u svim fazama razvoja informacijskog sustava. Detaljnost i formalnost projektnog plana trebaju biti razmjerne opsegu projekta i procjeni rizika. Dobre prakse nalau da projektni plan obuhvaa barem sljedee: jasan prikaz sadanjeg stanja (ukljuujui meuovisnosti s postojeim sustavom) te potreba korisnika i preciznu definiciju ciljeva projekta analizu isplativosti projekta koja e identificirati oekivane koristi i trokove razvoja sustava te procijeniti mogua alternativna rjeenja definiranje uloga i odgovornosti osoba koje e biti ukljuene u razvoj i isporuku sustava jasno razdvajanje dunosti izmeu osoba koje e biti zaduene za implementaciju informacijskog sustava i osoba koje e biti zaduene za kontrolu te implementacije; propisivanje postupaka komunikacije i izvjeivanja svih osoba koje e biti ukljuene u razvoj i isporuku sustava identifikaciju potrebne dokumentacije koja treba nastati u sklopu projekta razvoja informacijskog sustava
72
definiranje standarda za pisanje dokumentacije, koji e precizno opisati svrhu i formu svakog potrebnog dokumenta te uvjete pod kojima navedeni dokument nastaje planove testiranja planove izobrazbe osoba ukljuenih u projekt kako bi se on dovrio unutar planiranih vremenskih i financijskih okvira te da bi se uspjeno odravao novonastali sustav definiranje kontrolnih mehanizama koji e pratiti tijek projekta i aktivnosti koje se moraju poduzeti u sluaju odstupanja od projektnog plana.
8.1.2. Programski razvoj i isporuka sustava Programski razvoj informacijskih sustava moe se podijeliti (neovisno o odabranoj razvojnoj metodologiji i tehnologiji), izmeu ostalog, na sljedee procese: analizu i projektiranje programiranje testiranje uvoenje u produkcijski rad. U svakom od navedenih procesa moraju se primjenjivati odgovarajue procedure definirane pri planiranju i organizaciji projekta. Standardi programskog razvoja informacijskih sustava trebali bi biti dovoljno fleksibilni, kako se njima ne bi ograniavala kreativna i kvalitetna rjeenja. Dobre prakse nalau da razvojna, testna i produkcijska okolina budu meusobno odvojene na odgovarajui nain.
8.1.2.1. Analiza i projektiranje U postupku analize i projektiranja informacijskog sustava odgovorne osobe trebale bi podijeliti projekt u projektne zadatke koje e zaposlenici i druge osobe moi samostalno rjeavati (primjerice programeri). Pri analizi i projektiranju posebnu pozornost potrebno je posvetiti kontrolama sigurnosti. Isto tako, prilikom podjele projekta u projektne zadatke potrebno je izgraditi odgovarajuu dokumentaciju svakoga projektnog zadatka, koja bi morala sadravati barem sljedee: opis poslovnog procesa ili dijela poslovnog procesa koji e se implementirati projektnim zadatkom opis potrebnih funkcionalnosti procesa opisanog u projektnom zadatku ukljuujui (gdje je to mogue) i grafike prikaze meuovisnosti s postojeim poslovnim procesima i sustavom opis svih kontrola koje moraju biti ugraene u sustav opis ulaznih i izlaznih vrijednosti projektnog zadatka specifikaciju procesa koje treba zabiljeiti u operativnim i sistemskim zapisima popis osoba koje su zaduene za provedbu projektnog zadatka vremenski plan obavljanja projektnog zadatka
73
osnovni plan testiranja koji e pokazati da realizirani projektni zadatak daje oekivane rezultate.
8.1.2.2. Programiranje Dobre prakse nalau propisivanje standarda programiranja koji bi trebali obuhvatiti barem sljedee: principe i pravila pisanja programskog koda, nazivanja programskih dijelova, varijabla, elemenata baza podataka i slino obavezne kontrole koje treba ugraditi neovisno o specifinostima odreenoga projektnog zadatka principe i pravila upotrebe i dokumentiranja standardiziranih programskih rutina kako bi se izbjeglo dupliciranje programskoga koda. Aktivnosti programera trebale bi biti jasno definirane. Pristup programima izvan programerovih osobnih odgovornosti potrebno je ograniiti. Izvorni programski kod morao bi biti adekvatno zatien s obzirom na potrebu za odravanjem temeljnih naela informacijskog sustava.
8.1.2.3. Testiranje Prije putanja informacijskog sustava u produkcijski rad potrebno je provesti testiranje. Testiranje razvijenog sustava trebalo bi biti detaljno i na adekvatan nain kontrolirano, kako bi se utvrdilo odgovara li razvijeni sustav postavljenim ciljevima. Potrebno je propisati procedure testiranja te prije samog poetka testiranja izraditi detaljni testni plan. Testni plan trebao bi obuhvaati kombinacije kojima e se analizirati ponaanje sustava: u standardnim uvjetima u graninim sluajevima u svim realno zamislivim neregularnim situacijama. Testove je potrebno provoditi u kontroliranim uvjetima i upotrijebiti prethodno definirane podatke. Testni podaci trebali bi biti to sliniji pravim, produkcijskim podacima. Pri testiranju potrebno je voditi rauna o povjerljivosti informacija. Dobre prakse nalau verifikaciju rezultata testiranja tako da se usporede s unaprijed definiranim oekivanim rezultatima. Rezultati testova trebali bi se dokumentirati u standardiziranoj, propisanoj formi. Konane rezultate trebale bi prekontrolirati sve ukljuene strane te pisano potvrditi njihovu prihvatljivost.
8.1.2.4. Uvoenje informacijskog sustava u produkcijski rad Banka bi trebala propisati postupke uvoenja novih ili izmijenjenih sustava u produkcijski rad. Navedene procedure trebale bi definirati ovlasti, odgovornosti i nain prijenosa s testnog na produkcijsko okruenje. Prije uvoenja sustava u produkcijski rad potrebno je: organizirati izobrazbu svih zaposlenika koji e se tim sustavom sluiti svim korisnicima omoguiti pristup potpunoj korisnikoj dokumentaciji s jednostavnim, netehnikim opisom svih funkcionalnosti kojima e se sluiti u radu.
74
8.1.3. Odravanje informacijskih sustava Banka bi trebala definirati postupke odravanja informacijskih sustava i promjena tih sustava. Sve programske promjene trebale bi se strogo kontrolirati i dokumentirati kako bi se sprijeile bilo kakve neovlatene promjene te osiguralo odravanje temeljnih naela informacijskog sustava. Provoenje promjena trebalo bi biti u skladu s propisanim internim aktima banke vezanim uz upravljanje promjenama. Programske promjene veeg opsega treba tretirati kao zasebne projekte i na njih valja primijeniti ve navedene procese planiranja i formalne organizacije te programskog razvoja i isporuke informacijskih sustava. Banka bi trebala propisati standardne postupke za dokumentiranje programskih promjena informacijskih sustava koji trebaju obuhvatiti barem sljedee: identifikaciju programa ili sustava identifikaciju osobe koja je inicirala promjenu sustava datum kada je zatraena promjena sustava opis traene promjene odobrenje zatraene promjene. Prilikom izrade traenih promjena valja slijediti sve navedene smjernice za programski razvoj i isporuku informacijskih sustava. U sklopu analize, projektiranja, programiranja i testiranja sustava treba analizirati i dokumentirati sigurnosne rizike i negativne utjecaje koji mogu nastati na sustavu kao posljedica programske promjene. U odreenim uvjetima moe se pojaviti potreba za hitnom promjenom programa, zaobilaenjem standardnih postupaka provoenja promjena, odnosno izradom izvanrednih ili privremenih programskih promjena. Banka bi trebala propisati takve postupke koji e obuhvatiti barem sljedee: opis situacija u kojima se smiju provoditi izvanredne ili privremene programske promjene popis osoba ovlatenih za odobravanje izvanrednih ili privremenih programskih promjena kontrolne postupke za sprjeavanje zloporabe. Nakon to je sustav izmijenjen po hitnoj proceduri, izvanredne ili privremene programske promjene potrebno je dokumentirati kao i ostale promjene.
75
8.2. Eksternalizacija (dijela) informacijskog sustava

Nastojanje da se smanje trokovi poslovanja te potreba za visokom razinom usluga i vrlo visokom strunom osposobljenou zaposlenika esto nameu potrebu da banke eksternaliziraju poslovne procese (ili dio poslovnih procesa) te da se koriste uslugama pruatelja usluga kako bi ostvarile svoje strateke ciljeve. Koritenje usluga koje ine sastavni dio poslovnih procesa banke, a koje na temelju ugovora banci pruaju pruatelji usluga na kontinuiranoj osnovi i kojima se podrava pruanje bankovnih, financijskih i/ili pomonih bankovnih usluga od strane same banke, naziva se eksternalizacija (engl. outsourcing). Postupak nabave robe te ugovor(i) o nabavi robe (primjerice nabavi informacijske, hardverske i softverske imovine) ne smatraju se eksternalizacijom. Razliiti modeli eksternalizacije prisutni su ne samo u bankarskom sektoru nego u svim ostalim poslovnim sektorima. S obzirom na velik utjecaj eksternalizacije u svakodnevnom poslovanju banaka i rizik vezan uz eksternalizaciju, banke bi trebale na adekvatan nain upravljati odnosom s pruateljem usluga i nadzirati pruanje usluga u skladu s odredbama ugovora. Nadalje, banke bi trebale poduzeti potrebne korake kako bi se rizik eksternalizacije smanjio na prihvatljivu razinu s obzirom na to da se obujam aktivnosti i poslovnih procesa banaka koji su predmet eksternalizacije, ukljuujui i aktivnosti vezane uz informacijski sustav sve vie poveava. Predmetom eksternalizacije mogu biti razliite aktivnosti vezane uz informacijski sustav, primjerice: usluge odravanja hardvera usluge obrade podataka usluge razvoja poslovnih aplikacija usluge odravanja poslovnih aplikacija usluge upravljanja operativnim sustavima i usluge odravanja tih sustava usluge upravljanja telekomunikacijskim mreama i odravanja tih mrea usluge upravljanja bazama podataka i odravanja tih baza usluge upravljanja sigurnosnom infrastrukturom i odravanja te infrastrukture usluge upravljanja internetskim stranicama i odravanja tih stranica usluge e-bankarstva usluge upravljanja pozivnim centrima (engl. call-center) i odravanja tih centara usluge upravljanja centrima za pomo korisnicima (engl. help-desk) i odravanja tih centara usluge upravljanja podacima (skladitenje podataka, pronalaenje podataka - tzv. rudarenje - engl. data mining) i odravanja tih podataka. Za potrebe ovog dokumenta eksternalizacija aktivnosti vezanih uz informacijski sustav smatra se eksternalizacijom (dijela) informacijskog sustava. U nastavku teksta pojam eksternalizacija odnosi se na eksternalizaciju (dijela) informacijskog sustava.
Odluka o eksternalizaciji strateka je odluka banke, koja treba biti usklaena s poslovnom strategijom i ciljevima banke te, izmeu ostaloga, ovisi:
76
o sposobnosti banke da upravlja rizikom vezanim uz eksternalizaciju (dijela) poslovnih procesa o nainu nadzora i kontrole ugovorenih aktivnosti o usklaenosti s vaeim propisima.
Pruatelji usluga bankama mogu biti rezidenti i nerezidenti. S tim u svezi treba napomenuti da izravni nadzor koji provodi Hrvatska narodna banka u odnosu na pruanje usluga od strane pruatelja usluga rezidenta i/ili nerezidenta ne smije ni na koji nain i ni u kojem trenutku biti onemoguen, ogranien ili otean bez obzira na to obavlja li se na teritoriju Republike Hrvatske ili izvan njega. Radi postizanja prethodno navedenoga, ako je pruatelj usluga nerezident, banke bi svakako trebale prije donoenja odluke o izboru pojedinog pruatelja usluga utvrditi da li zakonodavstvo odnosno propisi drave u kojima dotini pruatelj usluga posluje, omoguavaju Hrvatskoj narodnoj banci da ostvari cjelovit i neogranien pristup djelatnostima i poslovima u svezi s kojima obavlja nadzor. Ugovor(i) i nalazi odnosno izvjea unutarnjih i vanjskih revizora vezani uz eksternalizaciju (dijela) poslovnih procesa trebali bi biti dostupni na hrvatskom jeziku zbog njihove bolje razumljivosti kako bi se tonije provelo analiziranje, ocjenjivanje i revidiranje aktivnosti koje su predmet eksternalizacije. Rizik u poslovanju postoji bez obzira na to hoe li banke same obavljati aktivnosti vezane uz informacijski sustav ili e se koristiti uslugama pruatelja usluga. Pri razmatranju svrhovitosti eksternalizacije aktivnosti vezanih uz informacijski sustav banke trebaju: biti svjesne rizika vezanog uz eksternalizaciju aktivnosti vezanih uz informacijski sustav osigurati da odnos izmeu banke i pruatelja usluga bude prihvatljiv sa stajalita rizika i u skladu s poslovnim ciljevima banke implementirati adekvatne zatitne mjere i kontrole kojima bi se smanjili identificirani rizici osigurati kontinuirano praenje rizika kako bi se identificirale i procijenile promjene u odnosu na inicijalnu procjenu rizika regulirati sve elemente i postupke koji se odnose na eksternalizaciju aktivnosti vezanih uz informacijski sustav svojim internim aktima.
77
Upravljanje rizikom eksternalizacije ukljuuje: procjenu rizika vezanog uz eksternalizaciju dubinsko ispitivanje (engl. due diligence) pruatelja usluga pri njegovu odabiru definiranje sadraja ugovora s pruateljem usluga osiguravanje kontinuiranog nadzora pruanja usluga u skladu s ugovornim obvezama osiguravanje neogranienoga i svakodobnog pristupa informacijama povezanim s uslugom koja je predmet eksternalizacije.
8.2.1. Procjena rizika vezanog uz eksternalizaciju Prije sklapanja ugovora s pruateljem usluga banka bi trebala procijeniti rizik eksternalizacije i mogunosti kontrole tog rizika. Pri toj procjeni potrebno je osobitu pozornost posvetiti procjeni rizika koji bi mogli utjecati na financijske rezultate, financijsku poziciju, kontinuitet poslovanja ili reputaciju banke. Za svaki pojedinani sluaj eksternalizacije (dijela) poslovnih procesa banka treba procijeniti rizik eksternalizacije. Kao dio procjene rizika eksternalizacije banka bi trebala procijeniti primjerice: strateki rizik, operativni rizik (npr. rizik gubitka podataka i kontrole nad znaajnim poslovnim procesima, rizik povezan s koritenjem informacijske tehnologije, rizik povezan s raspoloivou usluge, rizik prekida kontinuiteta poslovanja, transakcijski rizik i sl.), financijski rizik (primjerice rizik poveanja trokova), reputacijski rizik, pravni rizik (primjerice neusklaenost s propisima) te rizik zemlje podrijetla pruatelja usluga. Isto tako, banka treba procijeniti na koji e nain odnos s pruateljem usluga pomoi ostvarivanju stratekih ciljeva i zadovoljavanju poslovnih potreba banke. Pri procjeni rizika vezanog uz eksternalizaciju aktivnosti vezanih uz informacijski sustav banka bi trebala procijeniti sljedee: mogunost pruatelja usluga da osigura pruanje usluga u skladu sa stratekim ciljevima i poslovnim potrebama banke, pouzdanost, ekonomsku odrivost i sposobnost pruatelja usluga, nain na koji e banka nadzirati pruanje usluga, adekvatnost strunog osoblja u banci, odnosno je li ono u stanju provoditi kvalitetan nadzor nad pruateljem usluga i na adekvatan nain upravljati odnosom s pruateljem usluga, vanost, opseg i sloenost (dijelova) poslovnih procesa koji su predmet eksternalizacije, mogunost "vraanja" u banku (engl. reinsourcing) aktivnosti vezanih uz informacijski sustav koje e se eksternalizirati, za sluaj da pruatelj usluga ne postupa u skladu s odredbama ugovora ili ne odrava ugovorenu kvalitetu pruene usluge.
8.2.2. Dubinsko ispitivanje pruatelja usluga pri njegovu odabiru Nakon to je napravljena procjena rizika eksternalizacije banka bi trebala provesti dubinsko ispitivanje pruatelja usluga kako bi se utvrdilo moe li pruatelj usluga (financijski i operativno) pruiti banci zahtijevane usluge. Odabir sposobnoga i kvalitetnog pruatelja
78
usluga osobito je vaan kako bi se smanjio rizik eksternalizacije. Ovisno o utvrenim rizicima, banka bi trebala pri provedbi dubinskog ispitivanja uzeti u obzir sljedee: iskustvo pruatelja usluga i mogunosti pruanja potrebnih usluga radi ispunjenja postojeih i oekivanih potreba banke reputaciju i trini udio pruatelja usluga eventualne podizvoae pruatelja usluga koji e pruati podrku pruatelju usluga u ispunjavanju ugovornih obveza prema banci eventualnu potrebu za dodatnim sustavima, konverzijama podataka i uslugama sposobnost pruatelja usluga da na odgovarajui nain postupi u sluaju privremene nemogunosti pruanja usluga iz bilo kojeg razloga strunu osposobljenost odgovornih osoba koje e biti odreene za pruanje podrke banci lokaciju pruanja usluga kako bi se utvrdili uvjeti pod kojima pruatelj usluga djeluje i prua svoje usluge, revizorska i posljednja financijska izvjea pruatelja usluga mogunost neogranienog i svakodobnog pristupa svojim informacijama poznavanje propisa relevantnih za pruanje usluga koje su predmet eksternalizacije. Nadalje, banka bi trebala pri provedbi dubinskog ispitivanja pruatelja usluga ije je pruanje usluga vrlo vano za banku, uzeti u obzir i sljedee: adekvatnost internih akata pruatelja usluga koji se odnose: na upravljanje informacijskim sustavom na sigurnost informacijskog sustava na upravljake, logike i fizike kontrole na planiranje kontinuiteta poslovanja na upravljanje operativnim i sistemskim zapisima na razvoj i odravanje informacijskog sustava, adekvatnost kontrola primijenjenih kod pruatelja usluga financijske mogunosti investiranja i pruanja zahtijevane podrke od strane pruatelja usluga postojanje odgovarajueg osiguranja, ugovorenog od strane pruatelja usluga.
8.2.3. Definiranje sadraja ugovora s pruateljem usluga Uprava banke odgovorna je prema ZOB-u za svaku aktivnost koju za potrebe banke provodi pruatelj usluga. U ugovoru izmeu banke i pruatelja usluga treba definirati poslovne potrebe banke te regulirati imbenike rizika identificirane pri procjeni rizika eksternalizacije i dubinskog ispitivanja. Uprava banke duna je ugovornim odredbama osigurati zatitu bankovne i poslovne tajne, povjerljivost baninih podataka te omoguiti Hrvatskoj narodnoj banci obavljanje nadzora. Ugovori trebaju biti u pisanom obliku, jasno sastavljeni i dovoljno detaljni kako bi osigurali ispunjavanje preuzetih obveza koje se odnose na pruanje usluga. Isto tako, ugovori trebaju jasno definirati sve relevantne pojmove, uvjete, prava i obveze te odgovornosti ugovornih strana, pri emu minimalno trebaju sadravati sljedee odredbe:
79
detaljan opis usluga koje su predmet ugovora te nain ispunjenja ugovornih obveza odgovornost za tetu u sluaju povrede ugovornih obveza obvezu pruatelja usluga da prije zakljuenja ugovora s podizvoaem zatrai prethodnu pismenu suglasnost banke obvezu zatite bankovne i poslovne tajne te povjerljivosti baninih podataka detaljan opis prava i obveza ugovornih strana za sluaj prestanka ugovora, i to na nain koji e osigurati kontinuitet poslovanja banke pravo banke na pristup informacijama i vlasnitvo nad informacijama nain na koji e banka obavljati nadzor nad pruateljem usluga osigurati zaposlenicima Hrvatske narodne banke izravni nadzor djelatnosti i poslova u svezi s kojima Hrvatska narodna banka obavlja nadzor osigurati zaposlenicima Hrvatske narodne banke fiziki pristup resursima pruatelja usluga koji su neophodni za izvrenje usluga koje su predmet ugovora odgovornost pruatelja usluga za neobavljene, nepravodobne i neispravne transakcije i ostale ugovorene aktivnosti detaljan opis prava i obveza ugovornih strana koje e osigurati kontinuitet poslovanja banke u sluaju raskida ugovora identifikaciju kljunih kontrola, vremena odgovora na incidente, procedura i stupnjeva eskalacije u sluaju pojave nepredvienih dogaaja, pokrivenosti osiguranjem, mogunosti oporavka te drugih mjera upravljanja rizicima koje bi pruatelj usluga trebao primijeniti osigurati uvid u financijska izvjea, izvjea unutarnje i vanjske revizije kao i u ostala izvjea vezana uz poslovanje pruatelja usluga, a koja bi mogla biti relevantna za banku.
8.2.4. Osiguravanje kontinuiranog nadzora pruanja usluga u skladu s ugovornim obvezama Nakon sklapanja ugovora s pruateljem usluga banka bi trebala uvesti adekvatan sustav nadzora i kontinuirano ga provoditi kako bi kontrolirala nain pruanja usluga i kvalitetu pruenih usluga. Isto tako, banka treba utvrditi je li pruatelj usluga implementirao i primjenjuje li kontinuirano adekvatne kontrole vezane uz pruanje usluga koje su predmet ugovora. Kontrole trebaju biti barem jednake kontrolama koje bi bile primijenjene kad bi se dotine aktivnosti obavljale u banci. Banka treba osigurati struno osoblje koje je u stanju omoguiti kvalitetan nadzor nad pruateljem usluga i koje e na adekvatan nain upravljati odnosom s pruateljem usluga. Kontinuirani nadzor pruanja usluga u skladu s ugovornim obvezama treba obuhvaati barem sljedee: praenje i analiziranje kvalitete obavljanja usluga praenje svih injenica i okolnosti koje mogu utjecati na potrebu da se izmijeni ugovor praenje i analiziranje financijskog stanja te priljeva i odljeva kadrova kod pruatelja usluga kako bi se na vrijeme uoile financijske potekoe i izbjegli rizici za banku koji proizlaze iz nemogunosti pruanja ugovorenih usluga
80
procjenjivanje kvalitete revizorskih izvjea pruatelja usluga kako bi se ustanovilo jesu li opseg i dubina revizije adekvatni i u skladu s pravilima struke
Nadalje, banka bi trebala u sklopu provedbe nadzora pruatelja usluga ije je pruanje usluga vrlo vano za banku, obuhvatiti i sljedee: praenje i analiziranje sadraja i kvalitete internih akata pruatelja usluga kako bi se uoila eventualna odstupanja od zadanih smjernica i ugovornih obveza neposredan uvid na lokaciji pruanja usluga kako bi se utvrdila primjenjivost donesenih internih akata pruatelja usluga procjenjivanje rezultata testiranja plana kontinuiteta poslovanja i plana oporavka praenje postojanja odgovarajueg osiguranja, ugovorenog od strane pruatelja usluga.
8.2.5. Osiguravanje neogranienoga i svakodobnog pristupa informacijama Banci mora biti osiguran neogranien i svakodobni pristup informacijama koje su predmet eksternalizacije ili su na bilo koji nain povezane s eksternalizacijom (dijela) poslovnih procesa. Isto tako, banke bi trebale imati adekvatan plan kako bi se osigurao kontinuirani pristup informacijama i kontinuitet poslovnih procesa u sluaju neoekivanog prekida ili ogranienja pruanja usluga od strane pruatelja usluga.
81
9. E-bankarstvo
9.1. Uvod
Za potrebe ovog dokumenta elektroniko bankarstvo (u nastavku teksta: e-bankarstvo) definira se kao neposredna ponuda novih i tradicionalnih proizvoda i usluga klijentima putem elektronikih interaktivnih komunikacijskih kanala. E-bankarstvo ukljuuje sustave koji klijentima banke pruaju bankarske proizvode i usluge (to su primjerice pristup financijskim informacijama, voenje poslovanja, informiranje o proizvodima i uslugama, personalizirani financijski portali, agregirani rauni, elektroniko plaanje, elektroniki novac i slino). Budui da je uslugama i proizvodima e-bankarstva veim dijelom podrka informacijska infrastruktura banke koja je podrka i tradicionalnim distribucijskim kanalima, sve navedeno u ostalim poglavljima ovog dokumenta odnosi se i na e-bankarstvo. U ovom poglavlju naglasit e se specifinosti pojedinih zahtjeva koji proizlaze iz potrebe za adekvatnim upravljanjem rizicima povezanima s e-bankarstvom. E-bankarstvo moemo podijeliti u tri kategorije: 1. informativno: odnosi se na pruanje informacija klijentima o proizvodima i uslugama; iako rizik za banku u ovom sluaju nije velik, potrebno je uvesti kontrole kako bi se sprijeile neautorizirane promjene informacija koje se prezentiraju klijentima; 2. komunikacijsko: odnosi se na interakciju banke i klijenata (primjerice obuhvaa promjene osobnih podataka, traenje informacija o financijskim raunima kao to su stanja i transakcije, podnoenje zahtjeva za kreditom i slino); rizik je za banku bitno vei, posebice zato to u veini sluajeva postoji veza izmeu infrastrukture ebankarstva koja prezentira informacije i usluge klijentu te ostalih dijelova infrastrukture informacijskog sustava banke; 3. transakcijsko: odnosi se na provoenje transakcija (primjerice prijenos novca s rauna na raun, kupnja vrijednosnih papira i slino); rizik je najvei i u skladu s time trebaju biti primijenjene adekvatne kontrole. Stalne tehnoloke inovacije, irenje telekomunikacijskih kanala, a posebice interneta, te sve vea konkurencija na tritu omoguili su ubrzan razvoj postojeih i novih bankarskih proizvoda, usluga te naina isporuke, to stvara nove poslovne mogunosti za banke i njihove klijente. Iako samo e-bankarstvo nije uzrok nastanka novih rizika u poslovanju banaka, razvidno je da e-bankarstvo utjee na poveanje i promjenu karakteristika ve poznatih rizika u bankarskom poslovanju (primjerice stratekog, operativnog, pravnog i reputacijskog rizika). Neka od specifinih svojstava e-bankarstva, izmeu ostalog, ukljuuju: izrazito brze promjene vezane uz informacijsku tehnologiju promjenu oekivanja klijenata sve veu konkurenciju iroku dostupnost telekomunikacijskih mrea (primjerice interneta) sve manje tradicionalne komunikacije izmeu klijenta i banke integraciju aplikacija koje podravaju e-bankarstvo s tradicionalnim bankarskim aplikacijama veliku ovisnost banaka o dobavljaima i pruateljima usluga ubrzanu pojavu prijetnja i ranjivosti povezanih s telekomunikacijskim mreama.
82
Iz prije navedenog moe se zakljuiti da postojei sustav upravljanja rizikom u banci mora biti prilagoen kako bi adekvatno obuhvatio posebnosti rizika koje proizlaze iz specifinih svojstava e-bankarstva, opsega e-bankarstva u ukupnom poslovanju te mogunosti banke da upravlja rizicima. Sve navedeno poveava potrebu da se i prije uvoenja (nove) e-bankarske usluge provede procjena rizika e-bankarstva i izradi (aurira) strategija e-bankarstva.
83
9.2. Rizici povezani s e-bankarstvom

Brzim napretkom informacijske tehnologije i njezinim uvoenjem kao i tehnolokom sloenou poslova e-bankarstva posebno su poveani rizici povezani s e-bankarstvom odnosno operativni, reputacijski, pravni i strateki rizik. Banka bi trebala osigurati adekvatnost usluga e-bankarstva s obzirom na temeljna naela informacijskih sustava kako bi se smanjili prije navedeni rizici. Budui da klijenti banke oekuju svakodobnu raspoloivost usluge, banka bi trebala osigurati dovoljan kapacitet i redundanciju resursa informacijskog sustava kako bi usluge bile pouzdane i raspoloive. Nadalje, kako bi se banka zatitila od pravnog i reputacijskog rizika, usluge e-bankarstva moraju biti pruene na dosljedan i pravodoban nain u skladu s vaeim propisima i u skladu s korisnikim oekivanjima da e usluge biti brze i neprekidne. Isto tako, banka je duna pruiti svojim klijentima sigurnost s obzirom na povjerljivost i integritet podataka. uvanje povjerljivosti podataka klijenata zakonska je obveza banke pa postupanje protivno vaeim propisima izlae banku pravnom i reputacijskom riziku. Banka bi trebala na temelju procjene rizika primijeniti adekvatne zatitne mjere i kontrole koje e osiguravati zatitu povjerljivosti podataka o klijentima te donijeti pripadajue interne akte i standarde. imbenici koji odreuju pravni i reputacijski rizik povezan s e-bankarstvom proizlaze i iz injenice da je e-bankarstvo relativno nov distribucijski kanal kao i iz izrazito velikog poveanja upotrebe e-bankarstva. Neki od imbenika koji imaju utjecaj na pravni i reputacijski rizik jesu: neovlateno (namjerno ili sluajno) otkrivanje, mijenjanje ili unitavanje informacija gubitak povjerenja klijenata i javnosti zbog neovlatenih radnja na raunima klijenata neovlateno objavljivanje povjerljivih podataka nenamjerne greke i propusti poremeaji rada informacijskog sustava nemogunost pruanja usluge na oekivani nain (primjerice nezadovoljavajua funkcionalnost, raspoloivost i slino) pritube klijenata na tekoe pri koritenju usluge e-bankarstva neprimjereno upravljanje informacijskim sustavom nemogunost adekvatnog i pravodobnog odgovora banke na pritube klijenata. Strateki rizik moe proizai iz nedostatka jasno definiranih poslovnih ciljeva prema kojima se vrednuje uspjeh provedbe strategije e-bankarstva, loih i proturjenih poslovnih odluka, neadekvatne primjene poslovnih odluka te neprilagoivanja promjenama u okruenju. Prije donoenja odluke o uvoenju e-bankarstva banka bi trebala biti upoznata s rizicima povezanima s e-bankarstvom te napraviti analizu isplativosti odnosno procijeniti cjelokupne trokove uvoenja e-bankarstva i upravljanja njime.
84
9.3. Upravljanje rizikom e-bankarstva

Kao to je ve navedeno, upravljanje rizikom je proces procjene rizika, poduzimanja radnja za smanjenje rizika na prihvatljivu razinu i odravanja te razine rizika. Banka bi trebala osigurati da je upravljanje rizikom e-bankarstva sastavni dio sveobuhvatnog upravljanja rizicima kojima je banka u svom poslovanju izloena. Proces upravljanja rizikom i nadzor e-bankarstva trebaju provoditi osobe s adekvatnim strunim znanjima, bez obzira je li e-bankarstvo podrano u banci ili od strane pruatelja usluga. Isto tako, banka bi trebala nadzirati razvoj, implementaciju i odravanje sigurnosne infrastrukture koja e uinkovito tititi resurse e-bankarstva od unutarnjih i vanjskih prijetnja. Sigurnosna infrastruktura e-bankarstva i upravljanje njome ukljuuju barem sljedee: detaljne interne akte vezane uz e-bankarstvo logike i fizike kontrole, osobito kontrole pristupa primjerenu infrastrukturu koja ograniava aktivnosti korisnika informacijskog sustava dodjelu odgovornosti za nadzor razvoja, implementacije i odravanja pojedinih dijelova sigurnosne infrastrukture praenje aktivnosti radi sprjeavanja i otkrivanja neovlatenog pristupa i radnja na informacijskom sustavu kontinuirano revidiranje zatitnih mjera i kontrola (ukljuujui neprekidno praenje novih sigurnosnih trendova te instalaciju programskih ispravaka i nadogradnja). Budui da je uprava banke, izmeu ostalog, odgovorna i za razvoj poslovne strategije i djelotvorno upravljanje svim rizicima kojima je u svom poslovanju izloena, prije uvoenja usluge e-bankarstva trebala bi o tome donijeti eksplicitnu strateku odluku. Banka bi trebala provesti analizu isplativosti koja e biti podloga za donoenje odluke o uvoenju usluga i proizvoda e-bankarstva. Pri provoenju analize isplativosti potrebno je uzeti u obzir procijenjene rizike, trokove primjene zatitnih mjera i kontrola, vrijeme, tehniku kompetentnost i ostale resurse neophodne za adekvatno upravljanje i nadzor aktivnosti e-bankarstva (primjerice osoblje te hardversku, softversku i komunikacijsku podrku). Prilikom provoenja analize isplativosti uvoenja usluga i proizvoda e-bankarstva, potrebno je uzeti u obzir i sljedee imbenike: promjene u internim aktima banke i praksama utjecaj na funkcionalnost i sigurnost informacijskog sustava postizanje i odravanje primjerene mrene infrastrukture postizanje i odravanje kompetentnosti na podruju sigurnosti, sustava za podrku raspoloivosti sustava kao i sustava za otkrivanje neovlatenog pristupa i radnja na informacijskom sustavu praenje i nadzor pruatelja usluga i dobavljaa. Na temelju navedenog potrebno je donijeti strategiju e-bankarstva koja bi trebala uzeti u obzir razliite imbenike (primjerice elje i potrebe klijenata, konkurenciju, kompetentnost, trokove uvoenja i odravanja te postojea financijska sredstva) i biti u skladu s poslovnom strategijom banke. Zbog specifinosti rizika povezanih s e-bankarstvom u sklopu upravljanja tim rizicima potrebno je razmotriti sljedee:
85
nadzor i praenje e-bankarstva uspostavljanje kontrola sigurnost klijenta.
9.3.1. Nadzor i praenje e-bankarstva Djelotvoran sustav nadzora i praenja e-bankarstva nuan je za efikasno upravljanje i kontrolu nad e-bankarstvom te postizanje poslovnih ciljeva. Praenje i nadzor e-bankarstva trebali bi obuhvatiti cjelokupni proces e-bankarstva uzimajui u obzir: konfiguraciju i sigurnost mree meuovisnosti i veze s postojeim sustavom usuglaenost s vaeim propisima usuglaenost s internim aktima (primjerice s politikom sigurnosti informacijskog sustava) zatitne mjere i kontrole aktivnosti pruatelja usluga tehniku kompetentnost osoblja potrebu za odravanjem kontinuiteta poslovanja praenje neuobiajenih aktivnosti. Isto tako, banka bi trebala implementirati adekvatan sustav kontinuiranog nadzora u sluaju eksternalizacije (dijela) sustava e-bankarstva kako bi kontrolirala nain i kvalitetu pruanja usluga.
9.3.1.1. Planiranje kontinuiteta pruanja usluge e-bankarstva Banka bi trebala uspostaviti proces planiranja kontinuiteta pruanja usluge e-bankarstva koji bi trebao biti sastavni dio plana kontinuiteta poslovanja banke. Navedeno je potrebno kako bi se smanjio reputacijski, pravni i operativni rizik povezan s neraspoloivou ili neadekvatnom kvalitetom pruanja usluga e-bankarstva. U sklopu planiranja kontinuiteta pruanja usluge e-bankarstva banka bi trebala, izmeu ostalog, osigurati sljedee: analizu postojeih kapaciteta informacijskog sustava koji podravaju e-bankarstvo, ukljuujui procjenjivanje kapaciteta procesiranja transakcija e-bankarstva mogunost nadogradnje sustava e-bankarstva testiranje sustava e-bankarstva pod optereenjem (s obzirom na oekivani broj korisnika) ponovnu uspostavu ili zamjenu e-bankarskih procesnih mogunosti rekonstrukciju transakcija u sluaju potrebe procjenu ugovornih odnosa s dobavljaima i pruateljima usluga mogunost koritenja priuvnoga telekomunikacijskog kanala koji klijentima moe pruiti adekvatnu razinu usluge. Nadalje, pri planiranju kontinuiteta poslovanja banka bi trebala donijeti odgovarajui plan odgovora na incidente kako bi odgovorila na incidente koji nastaju zbog neoekivanih i
86
neeljenih dogaaja (kao to su unutarnji i vanjski napadi koji mogu imati negativne posljedice kad je rije o pruanju usluga e-bankarstva) radi njihova rjeavanja ili smanjenja. U sluaju nastanka incidenta, ukoliko su naruena prava odreenih klijenata banke, klijente je potrebno o tome obavijestiti.
9.3.1.2. Praenje neuobiajenih aktivnosti Dobre prakse nalau provoenje procjene rizika i razmatranje uvoenja djelotvornog i pravodobnog sustava praenja neuobiajenih aktivnosti koje se odnose na e-bankarstvo kao to su: transakcije e-bankarstva s neaktivnih rauna, vei broj transakcija u kraem razdoblju prema raunima s kojima do tada nije bilo transakcija (posebice ako ukupni preneseni iznos novca prelazi granini iznos novca koji podlijee odredbama Zakona o sprjeavanju pranja novca, "Narodne novine", br. 69/1997., 106/1997, 67/2001., 114/2001., 117/2003., 142/2003.), transakcije u offshore zone i slino promjena osobnih podataka klijenata (primjerice adrese klijenta), nakon koje slijede aktivnosti kao to su novi ekovi, nove zaporke, PIN-ovi koji se alju na tu adresu, poveanje limita, vei iznosi koji se prenose i ostalo. Navedeni slijed aktivnosti upuuje na moguu prijevaru. Nadalje, u sklopu sustava praenja neuobiajenih aktivnosti banka bi trebala razmotriti postupke komunikacije s klijentom te izvjeivanja odgovornih osoba i institucija.
9.3.2. Kontrole Uprava banke je odgovorna za uspostavu adekvatnog sustava kontrola e-bankarstva. Navedeno ukljuuje uspostavu upravljakih, logikih i fizikih kontrola na svim razinama. Zbog specifinosti rizika e-bankarstva posebnu pozornost valja posvetiti sljedeim imbenicima: identifikaciji, autentifikaciji i autorizaciji povjerljivosti integritetu podataka i transakcija raspoloivosti razdvajanju dunosti upravljanju operativnim i sistemskim zapisima sigurnoj i robusnoj infrastrukturi sustava e-bankarstva neporecivosti dokazivosti. Neki od navedenih imbenika detaljnije su razloeni u nastavku teksta.
9.3.2.1. Identifikacija, autentifikacija i autorizacija Banka je duna na temelju procjene rizika, koja obuhvaa i specifinosti e-bankarstva, donijeti standarde i ostale interne akte te u skladu s tim:
87
primijeniti sigurnu i djelotvornu tehnologiju autentifikacije za potvrdu identiteta i ovlasti osoba, procesa i sustava primjereno upravljati identifikacijskim i autentifikacijskim oznakama klijenata.
Prilikom procjene rizika potrebno je uzeti u obzir vrstu pojedine transakcije, osjetljivost informacija koje se prenose i pohranjuju te pouzdanost, sigurnost, provjerenost i nain primjene pojedine autentifikacijske metode. Autentifikacija klijenata trebala bi biti "jaka" odnosno ukljuivati najmanje dva od tri naina utvrivanja neospornosti korisnikog identiteta (detaljnije objanjeno u poglavlju "Upravljanje kontrolama pristupa").
9.3.2.2. Povjerljivost, integritet i raspoloivost E-bankarstvo poveava rizik od neovlatenog pristupa informacijama pri prijenosu javno dostupnom ili privatnom telekomunikacijskom mreom kao i onda kad su pohranjene u informacijskom sustavu banke. Kako bi se zatitila povjerljivost informacija, banka bi trebala osigurati barem sljedee: resursi informacijskog sustava trebaju biti dostupni samo ovlatenim i autentificiranim osobama, procesima i sustavima; resursi informacijskog sustava trebaju biti zatieni od neovlatenog otkrivanja ili mijenjanja za vrijeme prijenosa javno dostupnim i privatnim telekomunikacijskim mreama kao i pri pohranjivanju i uvanju informacija na sustavima banke; adekvatnu kontrolu pristupa pruatelja usluga koji imaju pristup povjerljivim informacijama; pristup osjetljivim informacijama ili bilo kakva modifikacija konfiguracije resursa informacijskog sustava (ija posljedica moe biti otkrivanje, unitavanje ili mijenjanje informacija) trebali bi se zapisivati u operativne i sistemske zapise. Neadekvatna zatita integriteta sustava i podataka moe dovesti do netonosti, prijevara ili pogrenih odluka, to moe biti prvi korak u naruavanju povjerljivosti i raspoloivosti sustava i podataka te smanjiti povjerenje u usluge e-bankarstva openito. Sve navedeno moe rezultirati poveanjem svih rizika kojima je banaka u svom poslovanju izloena. Kako bi ouvala integritet podataka, banka bi trebala implementirati adekvatne zatitne mjere i kontrole koje bi, uz potrebu ouvanja povjerljivosti, osigurale barem sljedee: e-bankarske transakcije trebaju se provoditi na takav nain da budu izrazito otporne na neovlatene utjecaje tijekom cijelog procesa; e-bankarske transakcije te procesi upravljanja podacima trebali bi biti planirani i izvedeni tako da rizik neprimjeivanja neovlatenih aktivnosti bude sveden na najmanju moguu mjeru; adekvatno upravljanje promjenama, ukljuujui praenje i testiranje sustava; primjenu kriptografskih metoda (primjerice banka bi trebala za prijenos osjetljivih informacija razmotriti uvoenje enkripcije od polazita do odredita informacije bez prijelazne dekripcije); aplikativne kontrole (primjerice za provjeru usklaenosti iznosa nakon izvrenja transakcija, kao i provjeru integriteta podataka prenesenih izmeu razliitih sustava); praenje neuobiajenih aktivnosti. Isto tako, jedna od vanijih karakteristika e-bankarstva jest raspoloivost usluge. Pojam raspoloivosti odnosi se na svojstvo mogunosti pristupa i upotrebljivosti na zahtjev
88
ovlatenog korisnika usluge e-bankarstva. Kako bi pruila zadovoljavajuu kvalitetu usluge ebankarstva, banka bi trebala osigurati primjerene kapacitete informacijske i telekomunikacijske infrastrukture te adekvatnu zatitu od namjernog ili sluajnog uskraivanja usluge. Neporecivost i dokazivost mogue je promatrati i kao kombinaciju naela povjerljivosti, integriteta i raspoloivosti. Banka bi trebala koristiti autentifikacijske metode kojima se osigurava neporecivost i dokazivost transakcija e-bankarstva. Rizik poricanja transakcija ve je prisutan pri tradicionalnim plaanjima kreditnim karticama, a e-bankarstvo poveava taj rizik: zbog kompleksnosti identificiranja, autentificiranja i autoriziranja osoba, procesa ili sustava koji iniciraju transakciju zbog mogunosti neovlatene promjene ili "prisvajanja" transakcija zbog mogunosti osporavanja transakcija e-bankarstva od strane korisnika. S obzirom na sve navedeno banka bi trebala ovisno o vrsti e-bankarske transakcije osigurati barem sljedee: sustavi e-bankarstva trebaju biti projektirani na nain kojim se smanjuje vjerojatnost iniciranja nenamjernih transakcija od strane ovlatenih korisnika; korisnici trebaju biti upoznati s rizicima povezanima s transakcijom koju zapoinju; osobe, procesi i sustavi trebaju biti identificirani i autentificirani; primjenu odgovarajuih kontrola nad autentificiranim kanalom.
9.3.2.3. Razdvajanje (segregacija) dunosti Razdvajanje dunosti je vrsta upravljake kontrole kojoj je cilj smanjiti rizik prijevare u poslovnim procesima te osigurati tonost i integritet podataka. Banka bi trebala primijeniti adekvatne kontrole radi djelotvornog razdvajanja dunosti u procesu e-bankarstva. Uobiajene prakse koje se koriste prilikom razdvajanja dunosti ukljuuju sljedee: transakcijski procesi i sustavi trebali bi biti projektirani tako da ni jedan zaposlenik banke ili osoba zaposlena kod pruatelja usluga ne moe samostalno zapoeti, autorizirati i zavriti transakciju; dunosti bi trebalo razdvojiti na dunosti onih (osoba, procesa i sustava) koji iniciraju poslovni proces u sklopu e-bankarstva i onih koji su odgovorni za verifikaciju integriteta tog procesa; potrebno je testirati sustav e-bankarstva kako bi se iskljuila mogunost zaobilaenja kontrola uvedenih radi razdvajanja dunosti; dunosti bi trebalo razdvojiti na dunosti osoblja koje razvija, osoblja koje testira i dunosti osoblja koje administrira sustav e-bankarstva.
9.3.2.4. Sigurnost aplikacija e-bankarstva Neprimjerena arhitektura aplikacija e-bankarstva poveava rizik koji proizlazi iz neovlatenih radnja. Banka bi stoga trebala osigurati primjerenu razinu sigurnosti sustava e-bankarstva adekvatnom arhitekturom aplikacije, imajui u vidu barem sljedee: odabir softverskih alata i tehnologije za razvoj e-bankarskih aplikacija s obzirom na znaajke sigurnosti;
89
potrebno je provoditi detaljnu i djelotvornu provjeru ispravnosti podataka (dobivenih javno dostupnim telekomunikacijskim mreama) u nadziranoj i sigurnoj okolini kako bi se smanjio rizik od obraivanja neispravnih podataka ili neovlatenog pristupa, radnja i slino; informacije koje sustav e-bankarstva uputi na suelje klijenta ne bi smjele otkrivati osjetljive informacije koje se odnose na arhitekturu aplikacije ili drugih resursa sustava e-bankarstva; povjerljive informacije koje se prosljeuju sa sustava e-bankarstva na suelje klijenta ili u suprotnom smjeru ne bi se trebale pohranjivati u privremene ili trajne resurse za uvanje podataka na ureaju klijenta bez njegova izriitog zahtjeva te ne bi smjele biti vidljive neovlatenim osobama; upravljanje aktivnim komunikacijskim kanalom e-bankarstva trebalo bi biti sigurno, to primjerice ukljuuje i njegovo zatvaranje odnosno prekidanje nakon razdoblja neaktivnosti klijenta.
9.3.2.5. Sigurnosna infrastruktura koja podrava e-bankarstvo Banka bi trebala uspostaviti adekvatno operativno okruenje koje podrava i titi sustav ebankarstva. Navedeno obuhvaa sigurnu infrastrukturu prema javno dostupnim telekomunikacijskim mreama, adekvatne zatitne mjere za lokalnu komunikacijsku mreu i veze prema drugim poslovnim subjektima. Nadalje, banka bi trebala implementirati hardversku i softversku podrku koja e: djelotvorno ograniavati radnje koje nisu neophodne detaljno nadzirati sve radnje koje su doputene i upravljati njima (primjerice primjenom vatrozida i sustava za otkrivanje neovlatenog pristupa i radnja na informacijskom sustavu). Potrebno je proaktivno i kontinuirano pratiti i nadzirati infrastrukturu prema javno dostupnim i privatnim telekomunikacijskim mreama kako bi se smanjio rizik koji proizlazi iz neprimjeivanja povreda sigurnosti, sumnjivih radnja, neovlatenog pristupa sustavima banke te ostalih prijetnja.
9.3.3. Sigurnost klijenata Kako bi banka smanjila pravni i reputacijski rizik, potrebno je prije zapoinjanja transakcije na distribucijskim kanalima osigurati adekvatnu informaciju o identitetu banke (primjerice ime banke i adresu sjedita banke, opis naina na koji klijenti mogu kontaktirati banku u svezi s problemima, prijedlozima, pritubama i slino). Isto tako, banka bi trebala osigurati adekvatnu potvrdu svog identiteta i autentinosti (primjerice upotrebom digitalnog certifikata) kako bi se smanjila mogunost neovlatenog predstavljanja u ime banke putem elektronikih distribucijskih kanala. Banka ne bi smjela traiti od klijenata informacije o identifikacijskim i autentifikacijskim oznakama putem komunikacijskih kanala koji ne osiguravaju odravanje temeljnih naela informacijskog sustava. Isto tako, banka bi svoje klijente trebala upoznati s moguim nainima provjere da li komuniciraju s bankom putem adekvatno osiguranoga slubenog elektronikog kanala distribucije (npr. oznaka sigurne transakcije ili provjera certifikata).
90
Nadalje, dobre prakse nalau da je klijente potrebno upoznati s injenicom da banka poduzima sve potrebne radnje kako bi osigurala adekvatnu zatitu usluge e-bankarstva. Kako bi se klijentu pruila odgovarajua sigurnost i kako bi se kontrolirao proces prijenosa novca kanalima e-bankarstva, dobre prakse nalau razmatranje sljedeeg: definiranja graninih iznosa transakcija (limita) odabira rauna koji mogu sudjelovati u transakcijama ovlasti klijenta za promjenu parametara transakcija (primjerice graninog iznosa, rauna) revidiranja korisnikih ovlasti ovisno o dotadanjem koritenju usluge e-bankarstva (primjerice izmjena graninih iznosa transakcija ovisno o razdoblju koritenja usluge, uvjetima koritenja, broju transakcija i slino) primjena adekvatne tehnologije identifikacije, autentifikacije i autorizacije s obzirom na tip klijenata, granine iznose i slino. Prilikom definiranja procesa odobravanja koritenja usluge e-bankarstva, kao i promjene parametara rauna klijenta, potrebno je definirati kriterije, naine i postupke: podnoenja zahtjeva odobravanja koritenja usluge e-bankarstva slanja povjerljivih podataka klijentima banke promjene osobnih podataka klijenata primjene tehnologija autentifikacije i autorizacije za spomenute procese.
91
10. Zakljuci i preporuke

Upravljanje informacijskim sustavom 1. Uprava banke trebala bi odrediti lana uprave koji e biti nadlean za nadzor i kontrolu procesa upravljanja informacijskim sustavom. Uprava banke trebala bi uspostaviti adekvatnu organizacijsku strukturu, odgovarajue funkcije i odbore te proces upravljanja rizikom informacijskog sustava kako bi se osiguralo primjereno upravljanje informacijskim sustavom. Uprava banke trebala bi delegirati ovlasti u skladu s uspostavljenom organizacijskom i funkcionalnom strukturom. Uprava banke trebala bi donijeti strategiju informacijskog sustava koja mora biti u skladu s poslovnom strategijom banke. Strategiju informacijskog sustava potrebno je razraditi u stratekim i operativnim planovima. Uprava banke trebala bi donijeti interne akte kojima se ureuje upravljanje informacijskim sustavom. Potrebno je definirati kriterije, naine i postupke izvjeivanja uprave banke. Uprava banke trebala bi imenovati voditelja organizacijske jedinice informacijske tehnologije, koji bi trebao biti usmjeren na strateka pitanja, funkcionalnost i djelotvornost informacijskog sustava u cjelini, te bi trebala definirati njegove ovlasti, odgovornosti i djelokrug rada. Uprava banke trebala bi uspostaviti neovisnu funkciju voditelja sigurnosti informacijskog sustava, koji bi trebao biti usmjeren na pitanja sigurnosti informacijskog sustava u cjelini, te bi trebala definirati njegove ovlasti, odgovornosti i djelokrug rada. Voditelj sigurnosti informacijskog sustava ne bi smio istodobno biti angairan na drugim funkcijama koje mogu stvoriti sukob interesa. Uprava banke trebala bi imenovati odbor za upravljanje informacijskim sustavom ili druge odbore ija je uloga praenje i nadziranje informacijskog sustava i njegovih aktivnosti te koordinacija inicijativa vezanih uz informacijski sustav, a koje se tiu usklaenosti s poslovnim ciljevima i stratekim planom banke. Banka bi trebala donijeti metodologiju upravljanja projektima kojom bi se definirali kriteriji, naini i postupci upravljanja projektima.
2.
3.
4.
5.
6. 7.
8.
9.
10.
Upravljanje rizikom informacijskog sustava 1. Upravljanje rizikom potrebno je uspostaviti kao kontinuirani proces procjene rizika, poduzimanja radnja za smanjenje rizika na prihvatljivu razinu i odravanja prihvatljive razine rizika.
92
2.
Banka bi trebala donijeti metodologiju upravljanja rizikom informacijskog sustava u kojoj bi se definirali kriteriji, naini i postupci upravljanja rizikom. Uprava banke trebala bi biti pisanim putem obavijetena o najznaajnijim rezultatima procjene rizika. Banka bi trebala odabrati i provesti mjere za smanjivanje rizika na prihvatljivu razinu. Banka bi trebala pri provoenju odabranih mjera uvesti nove i/ili izmijeniti postojee upravljake, logike ili fizike kontrole. Nakon provoenja odabranih mjera potrebno je utvrditi preostale rizike. Uprava banke trebala bi biti upoznata sa svim identificiranim preostalim rizicima te u skladu s time donijeti odluku o prihvaanju preostalih rizika ili poduzimanju radnja za daljnje smanjenje rizika. Banka bi trebala klasificirati informacije u razliite grupe prema stupnju njihove osjetljivosti s obzirom na mogue posljedice naruavanja temeljnih naela informacijskog sustava. Banka bi trebala donijeti interne akte kojima se definiraju kriteriji, postupci i odgovornosti za provoenje klasifikacije informacija. Banka bi trebala zatititi informacije na osnovi provedene klasifikacije informacija i procjene rizika.
3.
4.
5.
6.
7.
8.
9.
Unutarnja revizija 1. Unutarnja revizija treba biti organizirana tako da se osigura sustavno obavljanje revizije informacijskog sustava. Banka bi trebala donijeti metodologiju za provoenje unutarnje revizije informacijskog sustava temeljenu na procjeni rizika. Banka treba na temelju godinjeg programa rada unutarnje revizije donijeti i operativne planove rada za reviziju informacijskog sustava. Banka bi trebala kontinuirano obavljati unutarnju reviziju informacijskog sustava i definirati razdoblje unutar kojeg e obaviti reviziju cjelokupnoga informacijskog sustava. Izvjea o radu unutarnje revizije trebala bi sadravati i izvjea o obavljenim revizijama informacijskog sustava.
2.
3.
4.
5.
93
Sigurnost informacijskog sustava 1. Banka bi trebala donijeti politiku sigurnosti informacijskog sustava, upoznati korisnike informacijskog sustava s njom te imenovati osobu odgovornu za kontrolu provoenja te politike. Politika sigurnosti informacijskog sustava trebala bi sadravati naela upravljanja sigurnou informacijskih resursa te odgovornosti koje se odnose na sigurnost informacijskog sustava. Na temelju politike sigurnosti informacijskog sustava banka bi trebala donijeti i primijeniti detaljne interne akte koji se odnose na sve aspekte sigurnosti informacijskog sustava. Politiku sigurnosti informacijskog sustava potrebno je usklaivati s promjenama na informacijskom sustavu i u njegovoj okolini, u sluajevima naruavanja sigurnosti informacijskog sustava, te ovisno o rezultatima procjene rizika. Banka bi trebala definirati kriterije na temelju kojih e kontrolirati pristup resursima informacijskog sustava, te u skladu s definiranim kriterijima i procjenom rizika uvesti adekvatne upravljake, logike i fizike kontrole pristupa. Uvedene kontrole pristupa trebale bi biti u skladu sa standardima i pravilima struke. Banka bi trebala uspostaviti sustav upravljanja korisnikim pravima pristupa koji obuhvaa procese evidentiranja, autorizacije, identifikacije i autentifikacije te nadzora. Banka bi trebala posvetiti posebnu pozornost identifikaciji i autentifikaciji korisnika informacijskog sustava. Banka bi trebala posvetiti posebnu pozornost povlatenom i udaljenom pristupu resursima informacijskog sustava te ostalim pristupima koji, prema procjeni rizika, izlau banku poveanom riziku. Banka bi trebala u skladu s provedenom procjenom rizika odrediti adekvatne kriptografske metode ijom e se primjenom osigurati odravanje temeljnih naela informacijskog sustava. Banka bi trebala definirati i primijeniti postupke generiranja, pohrane, distribucije, aktiviranja, upotrebe, arhiviranja, zamjene, deaktivacije i unitavanja kriptografskih kljueva. Banka bi trebala, na osnovi provedene procjene rizika, primijeniti odgovarajue upravljake, logike i fizike kontrole radi fizike zatite prostorija s resursima informacijskog sustava, samih resursa, kao i sustava koji su podrka funkcioniranju informacijskog sustava. Banka bi trebala osigurati izradu, praenje i analizu operativnih i sistemskih zapisa kojima bi se omoguilo rekonstruiranje dogaaja, otkrivanje neovlatenih pristupa i
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
94
radnja na informacijskom sustavu, identificiranje problema i utvrivanje odgovornosti. 13. Operativni i sistemski zapisi moraju biti adekvatno zatieni od neovlatenog pristupa, izmjena i brisanja. Banka bi trebala primijeniti odgovarajue upravljake, logike i fizike kontrole kako bi se resursi informacijskog sustava zatitili od malicioznog koda. Kontrole je potrebno neprekidno nadzirati i redovito nadopunjavati.
14.
Odravanje informacijskog sustava 1. Banka bi trebala uspostaviti proces upravljanja imovinom informacijskog sustava koji obuhvaa detektiranje, evidentiranje, raspolaganje, praenje, planiranje, obnavljanje, zatitu i odlaganje imovine. Banka bi trebala uspostaviti proces upravljanja promjenama hardverskih softverskih komponenata informacijskog sustava banke koji obuhvaa postupke utvrivanja poetnih inaica softverskih i hardverskih komponenata informacijskog sustava te identifikacije i praenja svih promjena u vezi s njima. i
2.
3.
Banka bi trebala uspostaviti proces upravljanja konfiguracijama hardverskih i softverskih komponenata informacijskog sustava koji obuhvaa postupke analize, definiranja, dokumentiranja, testiranja, uvoenja u produkcijski rad, kontrole i praenja izmjena svih osjetljivih postavka komponenata informacijskog sustava. Banka bi trebala definirati postupke izrade, pohrane, odravanja i uvanja dokumentacije koja se odnosi na informacijski sustav banke. Dokumentacija bi trebala biti tona, potpuna i aurna. Banka bi trebala korisnicima informacijskog sustava osigurati pristup dokumentaciji koja je potrebna za obavljanje njihovih poslovnih zadataka. Banka bi trebala osigurati primjerenu izobrazbu svih korisnika informacijskog sustava koja e navedenim osobama omoguiti djelotvorno obavljanje poslovnih zadataka te smanjiti mogunost pojave neeljenih dogaaja na prihvatljivu razinu. Izobrazbu bi trebalo uspostaviti kao kontinuirani proces kako bi se osiguralo da znanja korisnika informacijskog sustava prate promjene u informacijskom sustavu i u njegovoj okolini.
4.
5. 6.
7.
Planiranje kontinuiteta poslovanja 1. Banka bi trebala uspostaviti proces planiranja kontinuiteta poslovanja kako bi osigurala postojanost kritinih i/ili vitalnih poslovnih procesa. Banka bi trebala izraditi i dokumentirati analizu utjecaja na poslovanje koja e odrediti utjecaj neraspoloivosti pojedinih poslovnih procesa odnosno resursa
2.
95
informacijskog sustava potrebnih za odvijanje tih procesa na poslovanje banke. Analiza utjecaja na poslovanje trebala bi posluiti kao podloga za planiranje kontinuiteta poslovanja. 3. Banka bi trebala usvojiti plan kontinuiteta poslovanja koji e osigurati ponovnu uspostavu kritinih i/ili vitalnih poslovnih procesa u zahtijevanom vremenu te ograniiti i smanjiti gubitke koji mogu nastati kao posljedica prekida poslovnih procesa. Plan kontinuiteta poslovanja treba se temeljiti na analizi utjecaja na poslovanje i procjeni rizika. Banka bi trebala usvojiti plan oporavka koji e osigurati raspoloivost resursa informacijskog sustava potrebnih za odvijanje kritinih i/ili vitalnih poslovnih procesa u zahtijevanom vremenu. Plan oporavka treba se temeljiti na analizi utjecaja na poslovanje i procjeni rizika. Banka bi trebala uspostaviti proces upravljanja incidentima te izraditi plan odgovora na incidente koji treba definirati procedure za postupanje u sluaju incidenata i odrediti osobe zaduene za odgovore na incidente te definirati njihov djelokrug rada, ovlasti i odgovornosti. Banka bi trebala, u sluaju teih incidenata, obavijestiti Hrvatsku narodnu banku o incidentu, njegovim uzrocima, uinku te nainu rjeavanja. Banka bi trebala upravljati priuvnom pohranom na nain koji ukljuuje postupke izrade, pohrane i testiranja priuvnih kopija te restauracije podataka kako bi se omoguila ponovna uspostava poslovnih procesa i osigurala temeljna naela informacijskog sustava. Banka bi trebala osigurati postojanje aurnih priuvnih kopija kao i provjerenih i testiranih metoda restauriranja podataka. Priuvne kopije trebale bi biti, u skladu s procjenom rizika, pohranjene i na udaljenu sigurnu lokaciju. Banka bi trebala, u skladu s procjenom rizika i analizom utjecaja na poslovanje, osigurati raspoloivost priuvnoga raunalnog centra na udaljenoj lokaciji s odgovarajuom opremljenou, funkcionalnou i sigurnou. Banka bi trebala testirati plan kontinuiteta poslovanja, plan oporavka i plan odgovora na incidente nakon znaajnih promjena u poslovnim procesima ili na informacijskom sustavu, a najmanje svakih 18 mjeseci. Potrebno je sastaviti pisana izvjea o rezultatima testiranja. Postupke izrade i pohrane priuvnih kopija potrebno je periodino, a najmanje jednom godinje, revidirati, kako bi se osigurala usklaenost navedenih postupaka sa zahtjevima koji proizlaze iz plana kontinuiteta poslovanja i plana oporavka. Postupke restauracije podataka s priuvnih kopija potrebno je periodino testirati, a najmanje jednom godinje, kako bi se osigurala usklaenost navedenih postupaka sa zahtjevima koji proizlaze iz plana kontinuiteta poslovanja i plana oporavka. Potrebno je sastaviti pisano izvjee o rezultatima testiranja.
4.
5.
6.
7.
8.
9.
10.
11.
12.
96
13.
Banka bi trebala testirati funkcionalnost i sigurnost priuvnoga raunalnog centra najmanje svakih 18 mjeseci. Potrebno je sastaviti pisano izvjee o rezultatima testiranja.
Razvoj sustava i eksternalizacija 1. Banka bi trebala definirati nain, kriterije, postupke i standarde razvoja informacijskih sustava, imajui u vidu funkcionalne i sigurnosne aspekte. Banka bi trebala proces razvoja informacijskog sustava organizirati kroz projekte. Projekte razvoja potrebno je planirati i formalno organizirati. Banka bi trebala projekte razvoja informacijskih sustava planirati i formalno organizirati kao sastavni dio procesa razvoja informacijskih sustava. Banka bi trebala uspostaviti i dokumentirati proces programskog razvoja i isporuke informacijskog sustava koji obuhvaa postupke analize i projektiranja, programiranja, testiranja i uvoenja u produkcijski rad. Banka bi trebala uspostaviti proces upravljanja programskim promjenama informacijskih sustava radi odravanja temeljnih naela informacijskog sustava. Banka bi trebala adekvatno razdvojiti razvojnu, testnu i produkcijsku okolinu. Prije donoenja odluke o eksternalizaciji banka bi trebala utvrditi da li zakonodavstvo odnosno propisi drave u kojima pruatelj usluga posluje omoguavaju Hrvatskoj narodnoj banci da ostvari cjelovit i neogranien pristup djelatnostima i poslovima u svezi s kojima Hrvatska narodna banka obavlja nadzor. Izravni nadzor od strane Hrvatske narodne banke u odnosu na pruanje usluga na teritoriju Republike Hrvatske i izvan njega od strane pruatelja usluga rezidenata ili nerezidenata ne smije ni na koji nain i ni u kojem trenutku biti onemoguen, ogranien ili otean. Prije donoenja odluke o eksternalizaciji (dijela) informacijskog sustava banka bi trebala procijeniti rizik eksternalizacije. Banka bi prije sklapanja ugovora s pruateljem usluga trebala provesti dubinsko ispitivanje pruatelja usluga. Banka bi trebala osigurati da odnos izmeu banke i pruatelja usluga bude prihvatljiv sa stajalita rizika i u skladu s poslovnim ciljevima banke. Ugovori izmeu Banke i pruatelja usluga trebaju biti u pisanom obliku, jasno sastavljeni i dovoljno detaljni kako bi osigurali ispunjavanje preuzetih obveza pruanja usluga. Isto tako, ugovori trebaju jasno definirati sve relevantne pojmove, uvjete, prava i obveze te odgovornosti ugovornih strana.
2.
3.
4.
5.
6. 7.
8.
9.
10.
11.
12.
97
13.
Banka bi trebala kontinuirano nadzirati pruanje ugovorenih usluga i upravljati rizikom eksternalizacije, ukljuujui i primjenu adekvatnih zatitnih mjera i kontrola kako bi se rizik eksternalizacije smanjio na prihvatljivu razinu. Banka bi trebala svojim internim aktima regulirati sve elemente i postupke vezane uz eksternalizaciju. Banci bi trebao biti osiguran neogranien i svakodoban pristup informacijama koje su predmet eksternalizacije ili su na bilo koji nain povezane s eksternalizacijom.
14.
15.
E-bankarstvo 1. Banka bi trebala donijeti strategiju e-bankarstva kao sastavni dio poslovne strategije banke. Banka bi trebala prije donoenja odluke o uvoenju e-bankarstva ili novih usluga procijeniti rizike povezane s e-bankarstvom i tim uslugama. Banka bi trebala osigurati djelotvoran sustav nadzora i praenja e-bankarstva. Banka bi trebala uspostaviti sigurnosnu infrastrukturu koja e djelotvorno tititi resurse e-bankarstva. Navedeno ukljuuje i uspostavu slojevitih upravljakih, logikih i fizikih kontrola. Banka bi trebala primijeniti sigurne i uinkovite autentifikacijske metode za potvrdu identiteta i ovlasti osoba, procesa i sustava. Autentifikacija osoba trebala bi biti "jaka" odnosno ukljuivati najmanje dva naina utvrivanja neospornosti identiteta. Banka bi trebala zatititi informacije od neovlatenog otkrivanja, mijenjanja ili brisanja za vrijeme unosa, obrade, prijenosa preko telekomunikacijskih mrea kao i pri pohrani i uvanju informacija na sustavima banke i klijenata. Banka bi trebala osigurati adekvatnu potvrdu svog identiteta na distribucijskom kanalu e-bankarstva kako bi klijent mogao provjeriti i potvrditi identitet i izvornost banke. Banka bi trebala osigurati postojanje operativnih i sistemskih zapisa za sve financijske i nefinancijske transakcije e-bankarstva. Banka bi trebala upoznati korisnike e-bankarstva s rizicima koritenja ebankarstvom.
2.
3. 4.
5.
6.
7.
8.
9.
98

H Smjernice Za Upravljanje Informacijskim Sustavom

Uploaded by

Copyright:

Available Formats

You might also like

H Smjernice Za Upravljanje Informacijskim Sustavom

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

H Smjernice Za Upravljanje Informacijskim Sustavom

Uploaded by

Copyright:

Available Formats

SMJERNICE ZA UPRAVLJANJE INFORMACIJSKIM SUSTAVOM U CILJU SMANJENJA OPERATIVNOG RIZIKA

Hrvatska narodna banka

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Hrvatska narodna banka

Hrvatska narodna banka

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Hrvatska narodna banka

1.1. Temeljna naela informacijskog sustava

Hrvatska narodna banka

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

1.2. Ciljevi, strategije i ostali interni akti

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Hrvatska narodna banka

1.3. Sigurnost informacijskog sustava

Hrvatska narodna banka

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

1.4. Elementi upravljanja rizikom

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Hrvatska narodna banka

Hrvatska narodna banka

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Hrvatska narodna banka

korigiranja oporavka nadzora osvjeivanja.

Hrvatska narodna banka

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

2. Upravljanje informacijskim sustavom

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Hrvatska narodna banka

regulatorne zahtjeve potrebe za resursima i nadzorom ogranienja.

Hrvatska narodna banka

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Hrvatska narodna banka

2.1. Uprava banke

Hrvatska narodna banka

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

2.2. Voditelj organizacijske jedinice za informacijsku tehnologiju

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Hrvatska narodna banka

2.3. Voditelj sigurnosti informacijskog sustava

Hrvatska narodna banka

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

2.4. Odbor za upravljanje informacijskim sustavom

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Hrvatska narodna banka

Hrvatska narodna banka

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

2.5. Upravljanje projektima

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Hrvatska narodna banka

Hrvatska narodna banka

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

3. Upravljanje rizikom informacijskog sustava

Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika

Hrvatska narodna banka