Tema broja. Ilustracija: Hrvoje Brekalo. 60 studeni MREŽA

Revizija informa Ilustracija: Hrvoje Brekalo 60 studeni 2012. MREŽA

cijskih sustava Gorak okus revizionizma Piše: Dalibor Uremović Ova mnogim informatičkim djelatnicima omražena aktivnost tek sad dolazi kao tema broja Mreže. Nije ni čudno: njen je rezultat uvijek skup loših stvari, prljavog rublja, nerada, pogrešaka i sličnih produkata kojima nije mjesto u učinkovitom upravljanju informacijskim sustavom. A opet, bez nje nema ni učinkovitog upravljanja. Glavni je cilj ove teme broja sprati gorak okus pri spomenu naziva revizije informacijskih sustava MREŽA studeni 2012. 61

Revizija informacijskih sustava Uvod u članak spominje gorak okus, a lako je zaključiti zašto je to tako. Nitko ne voli kad netko kopa po njegovu radu, kritizira i ističe pogreške te pametuje kako drugačije postaviti proces, implementirati kontrole u informacijskom sustavu, i još sve to iznosi pred menadžment. S obzirom na današnje karakteristike poslovanja koje rijetko dozvoljavaju temeljito izvođenje aktivnosti zbog kratkih rokova i konstantnog pritiska prodaje i razvoja poslovanja u kreiranju novih proizvoda i usluga, pogreške u radu postale su normalna pojava. U takvim okolnostima rijetko je moguće naći revizorski izvještaj koji nije pronašao nikakve probleme u području koje je revidirano te se menadžment s pravom može upitati: Pa dobro, zašto revizija stalno pronalazi probleme? Zar ih nismo riješili prošlim revizijama? Ako ovu situaciju sagledamo sa stajališta neke treće osobe (nije menadžment, revizor ili odgovorni djelatnik za revidiranu aktivnost), lako ćemo zaključiti da to uopće nije problem. Cilj revizije nije da pronađe ili ne pronađe nepravilnosti nego da ispita točnost, potpunost, vjerodostojnost, zakonitost i objektivnost procesa. Ako je to tako, rezultat revizije može nam postati jedan od najboljih prijatelja koje uopće možemo zamisliti i nije bitno ima li ili nema nepravilnosti. Sve bi strane trebale biti zadovoljne, pa makar se to odnosilo na kritiziranje rada koji je pod njihovom odgovornošću. Jasno je da se u ovako koncipiranom objašnjenju neće naći djelatnici koji izvode prevare s pomoću informacijskog sustava, odnosno oni koji konstantno krše postavljena pravila organizacije. U posljednje je vrijeme upućeno mnogo kritika na razna revizorska izvješća, bilo financijska ili vezana strogo uz informacijski sustav. One se uglavnom odnose na izvješća onih tvrtki koje su bankrotirale, izgubile silne milijune zbog loših poslovnih odluka ili financijskih prevara, a koja nisu pokazivala nepravilnosti, odnosno prikazivala su status kao da je sve bilo u najboljem redu. Ovo može odati dojam da su revizije postale pro forma aktivnost, nešto što se mora obaviti zbog regulatornih zahtjeva, a pritom netko u džep stavlja lovu za neodrađeni posao. Da odmah razjasnimo: ovo je moguć scenarij, ali je isto tako činjenica da se postupci revizije temelje na uzorkovanju i odabiru opsega u kojem se realno problemi i ne moraju pojaviti. Regulativa Kako je uopće došlo do razvoja ove poslovne grane koja doživljava sve veći porast? Dva su glavna izvora zahtjeva za izvođenjem revizije. Jedan je pojava sve brojnije regulative iz područja informacijskih sustava koja obavezno u svom dije lu ima i poglavlja revizije. Najbolji su primjeri za to direktiva Basel II (Stup II), SOX, PCI DSS te kod nas poznata Odluka o primjerenom upravljanju informacijskim sustavom koju je izdala Hrvatska narodna banka. Svi ovi, kao i mnogi drugi regulatorni zahtjevi u ostalim krajevima svijeta, u nekom obliku navode potrebu revizije postavljenih kontrola u informacijskom sustavu. Neki od poznatih sigurnosnih incidenata Godina Organizacija Opis incidenta 2007. TJX Companies Zbog nezaštićene bežične mreže ukradeni podaci 94 milijuna kreditnih i debitnih kartica. 2007. HM Revenue & Customs Izgubljena dva diska s osobnim podacima 25 milijuna obitelji u Velikoj Britaniji. 2007. HSBC bank Kazna od 3,2 milijuna funti zbog gubitka podataka životnog osiguranja od 180.000 klijenata. Uzrok je izgubljeni disk u pošti na kojem podaci nisu bili kriptirani. 2008. Bank of New York Mellon Ukradene trake s pričuvnom pohranom podataka iz sistemske sobe. Disk je sadržavao osobne podatke 12,5 milijuna klijenata. 2009. Heartland Payment Systems Izgubljeno oko 130 milijuna podataka o transakcijama zbog infekcije informacijskog sustava zloćudnim kodom. 2011. Sony Playstation Network Ukradeno cca. 24 milijuna osobnih podataka, transakcija, zaporki i sl. korisnika Sony Playstation mreže. Gubitak se procjenjuje na 171 milijun dolara. 2001. Dio hrvatskih telekoma Poznati DDoS napad 21. travnja 2001. Napadnuti su hrvatski internetski poslužitelji, što je imalo za posljedicu nemogućnost pristupa Internetu na neko vrijeme. 2002. Riječka banka Nestalo je oko 75 milijuna eura putem transakcija koje je godinama vodio diler Riječke banke. Zakazao je kompletan sustav unutarnjih kontrola. Regulatorni zahtjevi i tehnološki standardi vezani uz informacijske sustave prema kojima je moguće raditi reviziju usklađenosti Kako je čest uzrok donošenja nekog zakona i regulatorskog akta pojava nekog problema u stvarnom svijetu, nije teško pretpostaviti da su i gore navedeni zahtjevi nastali upravo zbog toga. Svaki put kada bi se pojavio neki veći problem, mudre bi glave sjele i pokušale donošenjem regulative dotjerati stvari u red. SOX je, primjerice, nastao ponajviše zaslugom sloma Enrona, WorldComa i nekoliko drugih većih kompanija uslijed prikazivanja netočnih financijskih izvješća. Kako se podaci za izvješća neposredno izvlače iz informacijskih sustava tih tvrtki, jedan je od problema bio i nedostatak kontrola nad informacijskim sustavom koji je doveo do problematičnih izvješća. U kontekstu ove teme broja, zanimljiva je sekcija 404 regulative SOX koja govori o reviziji sustava unutarnjih kontrola. S drugom verzijom sporazuma Basel ponešto je drugačija priča. Premda se nastanak ovog sporazuma više može pripisati preventivnom razmišljanju o poboljšanju sigurnosti financijskog sektora, prodor direktiva ovog sporazuma bio je relativno spor. Naravno da se cijela stvar drastično ubrzala tek nakon izbijanja financijske krize 2008. godine, nakon čega je postalo jasno zašto je potrebno primijeniti strože mehanizme kontrole, procjene rizika i supervizije kako bi se izbjeglo ono što se upravo i dogodilo. PCI DSS (Payment Card Industry Data Security Standard) također je nastao zbog niza propusta koji su prethodili dogovoru oko ovog standarda, prvenstveno vezanih uz razne hakerske napade na kartičarske kuće te otkrivanja povjerljivih podataka nositelja kartica. Primjeri su za to provale informacijskog sustava u OmniAmerican Bank, Heartland Payment Systems, TJX Companies i sl. Neke od poznatih sigurnosnih incidenata vezanih uz gubitak povjerljivosti podatka informacijskog sustava možete pogledati u okviru sa strane. 62 studeni 2012. MREŽA

Dobre prakse Ako je prvi izvor zahtjeva za izvođenjem revizije informacijskih sustava pojava regulative, drugi je izvor u brojnim standardima i dobrim praksama upravljanja informacijskim sustavom proizašlima iz sustavnog promišljanja o tome kako moraju biti uspostavljeni tipični IT procesi u nekoj organizaciji. Ovo je bitno za reviziju informacijskih sustava jer s njima dobivamo okvir odnosno set procesa i kontrola za koje trebamo provjeriti postoje li i u kojoj su mjeri implementirani kako je propisano dobrim praksama. U moru dobrih praksi čini se da je na površinu isplivalo nekoliko njih, a prvenstveno ITIL, CobiT, odnosno ISO 27002. O svakom detaljnije pročitajte u sljedećem članku. Ovaj dio revizije često nazivamo provjerom usklađenosti (engl. compliance) i predstavlja jedan važan dio IT GRC segmenta tržišta koji je posljednjih nekoliko godina u silovitom zamahu. Prošle godine je primjerice Forrester Research predvidio rast IT GRC tržišta od 20-ak posto, a AMR Research u svom istraživanju navodi podatak da je 2010. godine IT GRC tržište vrijedilo oko 30 milijardi dolara. IT GRC inače je kratica za IT Governance, Risk Management and Compliance. Revizija informacijskih sustava u Hrvata Revizija informacijskih sustava polako se probija u posebnu granu ICT industrije kojoj samo fali završna potvrda u vidu formalnog državnog certifikata koji bi uveo još malo više reda u relativno dobro funkcionirajuće tržište. Naime, obrazovni je sustav obogaćen predmetima vezanim uz reviziju informacijskih sustava na većini fakulteta tehničkih znanosti, a neki od njih (npr. FOI) imaju i poseban studij posvećen upravo tome. U Hrvatskoj također djeluje Udruga za reviziju i kontrolu informacijskih sustava u sklopu koje djeluje i hrvatski ISACA ogranak, a certifikat CISA postao je de facto standard za revizore informacijskog sustava. Grafički prikazi sukladnosti s poznatim standardima česta su pojava u alatima za podršku reviziji MREŽA studeni 2012. 63

Revizija informacijskih sustava Usklađivanje na sto Plan Do Act Check PDCA ciklus koristi se u svim standardima upravljanja informacijskim sustavom Dobre prakse upravljanja informacijskim sustavom čine temelj revizorskog posla. Osim provjere izvode li se procesi u skladu s regulativom i internim aktima organizacije, moramo provjeriti i jesu li procesi osmišljeni i implementirani u skladu s općeprihvaćenim svjetskim standardima 64 studeni 2012. MREŽA Revizija informacijskih sustava mora provjeriti IT procese, odnosno uspostavljene kontrole u informacijskom sustavu, s više stajališta. Pravno gledajući, najvažnije je ustvrditi da je rad informacijskog sustava u skladu sa zakonima. U istu grupu zahtjeva možemo ubaciti i poštovanje regulatornih i raznih drugih ugovornih obveza. Nepoštovanje ove prve dvije grupe zahtjeva vrlo lako dovodi do financijskih gubitaka tvrtke. S druge strane, menadžment također zanima slijede li se interno doneseni akti, propisane politike i procedure, jesu li učinkovite te u skladu s dobrim praksama međunarodnih standarda. Kako je prva grupa zahtjeva specifična za područje poslovanja određene tvrtke, osim standardnih Zakona o zaštiti osobnih podataka ili primjerice Zakona o informacijskoj sigurnosti, u ovom ćemo se članku pozabaviti ovom drugom grupom zahtjeva kojima je podvrgnut informacijski sustav. U mnoštvu dobrih praksi upravljanja informacijskim sustavom malo je više riječi posvećeno trima najzastupljenijima, ali to ne znači da neki od standarda koji ovdje nisu spomenuti nije dobar. Najčešći je slučaj da se tada radi o standardu ograničenom na određenu regiju/državu ili je bolje odnosno slabije prihvaćen u različitim dijelovima svijeta. PDCA ciklus Ono što je zajedničko svim standardima jet da propisuju tipične procese koji se pojavljuju tijekom rada informacijskog sustava, odnosno kontrole koje je potrebno uspostaviti da bi upravljanje informacijskim sustavom bilo sigurno i učinkovito. Pritom svi oni koriste poznati model PD CA ciklusa u kojem se ista pažnja posvećuje i onome što proces ili kontrola radi (Do faza) i planiranju te reviziji izvođenja procesa (Plan odnosno Check faza), što se često zaboravlja propisati i implementirati pri uvođenju nekog novog procesa. Pokušajte pogledati dokumente koji propisuju neki od procesa u vašoj tvrtki pa ćete lako uočiti da aktivnostima planiranja, provjere i nadzora te korektivnih akcija nije posvećeno nijedno poglavlje, ili su opisani samo grubim crtama. Ako to nije slučaj, na dobrom ste putu da se propisani procesi u vašoj tvrtki uspješno implementiraju.

načina Status usklađenosti Ako se revizija radi isključivo prema nekom od standarda upravljanja informacijskim sustavom, onda govorimo o reviziji statusa usklađenosti. Mnoge tvrtke baziraju upravljanje svojim informacijskim sustavom na općepoznatim standardima kao što su CobiT, ITIL, ISO 27001 i sl. te žele znati jesu li na dobrom putu. Jednostavna provjera zahtjeva koje ti standardi preporučuju daje nam postotak usklađenosti, a preporuke u tom slučaju nisu ništa drugo nego isti ti zahtjevi prepisani u revizorski izvještaj. Kako je već rečeno na početku, revizija informacijskih sustava kakvu možemo naći u našim tvrtkama, bilo da je vanjska ili interno provedena, često kombinira više takvih standarda te napisane preporuke u velikoj mjeri ovise o stručnosti i iskustvu revizora koji ih piše. Cobit 5 Processes for Governance of Enterprise IT Evaluate, Direct and Monitor EDM01 Ensure Governance Framework Setting and Maintenance EDM02 Ensure Benefits Delivery Kako je tema ovog broja revizija informacijskih sustava, a CobiT standard koji najviše pažnje posvećuje upravo tom aspektu upravljanja informacijskim sustavima, njemu će se dati i najviše pažnje. Ovaj je standard u svojim počecima bio najviše usmjeren na definiranje kontrolnih ciljeva i njihovu provjeru putem revizije, a u trenutnoj inačici standarda (verzija 5) još su naglašeniji procesi upravljanja, planiranja i usklađivanja IT ciljeva s poslovnim ciljevima organizacije. CobiT donosi procesni model temeljen na općem PDca ciklusu putem četiri domene: Align, Plan and Organize (1); Build, Acquire and Implement (2); Deliver, Service and Support (3) i Monitor, Evaluate and Assess (4). Novom inačicom standarda dodana je i domena Evaluate, Direct and Monitor, koja je usmjerena prvenstveno na osmišljanje upravljačkog okvira te mehanizme ostvarivanja zacrtane strategije definirane tim okvirom. Standard je izdao ITGI (IT Governance Institut), a o njemu se aktivno skrbi Isaca, međunarodna udruga profesionalaca vjerojatno najpoznatija po svom certifikatu CIsa (Certified Information System Auditor). Ova udruga djeluje i u Hrvatskoj, mada s većim turbulencijama u posljednjih godinu dana. Isaca je izdala mnoštvo publikacija o CobiT-u, a sa stanovišta revizije najzanimljiviji je IT Assurance Guide koji propisuje najbolje prakse pri reviziji informacijskih sustava. Ova je publikacija de facto standard za reviziju informacijskih sustava, koji se često primjenjuje zajedno s međunarodnim revizijskim standardima kako bi revizija dala sveobuhvatne, usporedive te metodološki kreirane rezultate. EDM03 Ensure Risk Optimisation EDM04 Ensure Resource Optimisation EDM05 Ensure Stakeholder Transparency Novi CobiT dodaje novu razinu upravljačkim procesima s nekoliko izmjena u dosadašnjim procesima u odnosu na stari standard Align, Plan and Organise APO01 Manage the IT Management Framework APO08 Manage Relationships APO02 Manage Strategy APO09 Manage Service Agreements APO03 Manage Enterprise Architecture APO10 Manage Suppliers APO04 Manage Innovation APO11 Manage Quality APO05 Manage Portfolio APO12 Manage Risk APO06 Manage Budget and Costs APO13 Manage Security APO07 Manage Human Resources Monitor,Evaluate and Assess MEA01 Monitor, Evaluate and Assess Performance and Conformance Build, Acquire and Implement BAI01 Manage Programmes and Projects BAI08 Manage Knowledge BAI02 Manage Requirements Definition BAI09 Manage Assets BAI03 Manage Solutions Identification and Build BAI10 Manage Configuration BAI04 Manage Availability and Capacity BAI05 Manage Organisational Change Enablement BAI06 Manage Changes BAI07 Manage Change Acceptance and Transitioning MEA02 Monitor, Evaluate and Assess the System of Internal Control Deliver, Service and Support DSS01 Manage Operations DSS02 Manage Service Requests and Incidents DSS03 Manage Problems DSS04 Manage Continuity DSS05 Manage Security Services DSS06 Manage Business Process Controls MEA03 Monitor, Evaluate and Assess Compliance With External Requirements Processes for Management of Enterprise IT MREŽA studeni 2012. 65

Revizija informacijskih sustava itil ITIL (Information Technology Infrastructure Library) je najopširniji standard koji često dotiče i pitanje kako nešto napraviti, a ne samo što. Posljednja inačica - v3 - organizirana je u pet knjiga i kompletno je usmjerena na pitanje pružanja IT usluga u svrhu ostvarivanja poslovnih ciljeva. Tri knjige obrađuju osnovne IT procese: Service Design, Service Transition i Service Operation. U njima je, primjerice, moguće naći opis kreiranja kataloga IT servisa, procesa upravljanja promjenama ili konfiguracijama informacijske imovine, ali i operativne IT procese poput upravljanja incidentima, pravima pristupa i sl. Preostale dvije knjige razmatraju upravljački dio planiranja, nadzora i kontinuiranog poboljšavanja rada informacijskog sustava. Kako je ITIL najkonkretniji od svih standarda u smislu implementacije predloženih procesa odnosno kontrola, često se koristi pri razvoju uslužnih IT alata za podršku ovim procesima pa je de facto zahtjev da bilo koji alat iz područja upravljanja incidentima, podrške service desku ili upravljanja konfiguracijama bude u skladu s posljednjom verzijom ITIL-a. Gledajući u kontekstu revizije informacijskih sustava, upravo nam to i pomaže prilikom testiranja kontrola gore navedenih procesa, koji su u većini tvrtki već podržani odgovarajućim alatima. Kao što je rečeno, u ITIL-u se sve vrti oko definiranja poslovnih i IT servisa te implementacije procesa koji osiguravaju njihov rad i kontinuirano poboljšanje. Inače, od svih navedenih standarda, ITIL najmanje pažnje posvećuje aktivnostima periodične i nezavisne revizije informacijskih sustava te ga, za razliku od CobiT-a, možemo uzeti samo kao mjerilo u odnosu na koje radimo reviziju, a ne i za metodološki okvir po kojem će se revizija izvoditi. Organiziran u pet knjiga, ITIL je okrenut prema servisnom modelu upravljanja IS-om 11 (+1) područja koja pokriva standard ISO 27002 ISO 27002 Odmah na početku razriješimo dilemu koja se često može čuti u razgovorima o standardu ISO dvajsedamtisuća. Naime, 27000 je grupa više standarda koji pokrivaju područje upravljanja informacijskom sigurnošću. Najpoznatiji je među njima ISO 27001, koji propisuje zahtjeve prema kojima je tvrtku moguće certificirati, što je i jedan od najčešćih razloga implementiranja ovog standarda. No certifikacija je teško izvediva bez standarda ISO 27002, koji predstavlja skup dobrih praksi za implementaciju kontrola vezanih uz sigurnost informacijskih sustava. Da podsjetimo, certifikacija se ne radi po ovom standardu! Kako je tema ovog broja revizija informacijskih sustava, nama je interesantniji ovaj drugi standard jer nam propisane dobre prakse daju izvor informacija o tome što je potrebno testirati prilikom izvođenja revizije. Ove dobre prakse odnose se na kontrole koje je potrebno implementirati kako bismo podigli razinu sigurnosti informacijskog sustava. Pojam sigurnost u ovom se slučaju odnosi na zaštitu povjerljivosti informacija, što je prva asocijacija na tu riječ, ali i na očuvanje cjelovitosti i raspoloživosti informacija, pa samim tim kontrole obuhvaćaju velik dio tipičnih IT procesa, čime se pokriva i onaj dio upravljačkih mehanizama. Općenito se može reći da se veći dio svih standarda preklapa i organizacija neće mnogo pogriješiti ako se odluči za implementaciju bilo kojeg od njih. 66 studeni 2012. MREŽA

Metodologija revizije Revizija informacijskih sustava toliko je široko područje da za nju postoji i poseban studij na jednom od naših fakulteta. Logično je onda i da su za nju razvijene razne metodologije, a za sve vrijede ista tri pitanja: što, kako, čime? Odgovorimo prvo na pitanje što?. Jedna od definicija glasi: revizija informacijskog sustava jest sistematično istraživanje sadržaja, implementacije i efektivnosti odabranih aspekata upravljanja informacijskim sustavom organizacije ili dijela organizacije. Nastaje odlukom organizacije kao odgovor na neku zakonsku obvezu, obvezu koju ima u sklopu svojih implementiranih politika ili na osnovu raznih potreba za poboljšanje učinkovitosti upravljanja informacijskim sustavom unutar organizacije. Osim pitanja što je revizija, potrebno je odgovoriti i na pitanje: što je opseg revizije?. Jednostavni je odgovor sve, što daje neprihvatljiv zahtjev za reviziju ako želi striktno slijediti sva pravila neke od metodologija. Sve se stoga mora iscijepati na više područja koja će se revidirati tijekom godine ili više godina (preporuča se da se obuhvati cijeli informacijski sustav u najviše tri godine), odnosno primijeni metodologija koja će u kraćem vremenu uspjeti obuhvatiti sva područja informacijskog sustava. Što to ulazi u pojam sve, obrađeno je prethodnim člankom. Opseg revizije prije svega je određen tipom revizije (v. okvir) te je uobičajeno da se pri reviziji prve strane (ili internoj reviziji) ona provodi kontinuirano tijekom cijele godine, a godišnji plan uglavnom slijedi revizije pojedinih organizacijskih funkcija ili poslovnih procesa i područja po mjesecima ili kvartalima. Revizije druge i treće strane uglavnom traju određeno razdoblje (npr. mjesec dana) jednom godišnje te se temeljem procjene rizika odabiru najkritičnija područja, a uzorci nad kojima se provodi revizija kudikamo su manji. Sa stajališta konteksta sadržaja, revizija informacijskog sustava obuhvaća kontrolu izvođenja propisanih politika i procedura, provjeru sukladnosti s dobrim praksama upravljanja informacijskim sustavom (primjerice CobiT, ITIL, ISO 27002, Smjernice HNBa za primjereno upravljanje informacijskim sustavom i sl.) te procjenu rizika informacijskog sustava. Procjena rizika Procjena rizika standardni je korak koji je potrebno napraviti ako se želimo fokusirati na određeni segment informacijskog sustava. Ovim se osigurava da se opseg revizije ograniči na one dijelove informacijskog sustava s najvišim identificiranim rizicima te se olakša uzorkovanje. Kako je procjena rizika aktivnost koja je već više puta obrađivana u nekim drugim člancima ovog časopisa, ovdje ćemo se zadržati samo na načinu procjene rizika informacijskog sustava u kontekstu odabira opsega odnosno programa revizije. Ova procjena rizika često nije jako formalizirana, a njena kvaliteta ponajviše ovisi o stručnosti i iskustvu revizora. Izvodi se na temelju grubih informacija o informacijskom sustavu koje je potrebno prikupiti putem kraćih intervjua, pregledom dokumentacije te neposrednim promatranjem implementiranih kontrola. Rezultat su procjene rizika po veličini rizika rangirana područja koja nam potom postaju dio opsega revizije. Izvođenje revizije Nakon definiranja opsega revizije potrebno je napisati program revizije i detaljni plan izvođenja. Plan izvođenja obično sadrži popis područja odnosno intervjua s odgovornim djelatnikom za neko područje sistematiziran po danima revizije. Plan je sklon promjenama tijekom samog izvođenja revizije, a jedna od važnijih sposobnosti revizora jest da uspješno barata zahtjevima revidiranih djelatnika za promjenama MREŽA studeni 2012. 67

Revizija informacijskih sustava Svijetli primjer Reviziji informacijskih sustava trenutno se najviše pažnje pruža u financijskom sektoru. Mora se priznati da Hrvatska narodna banka daje jak ritam razvoju metodologije revizije, pogotovo glede izvođenja vanjske revizije informacijskog sustava kreditnih institucija. Tako HNB redovno organizira sastanke s vanjskim revizorima informacijskih sustava na kojima se prezentiraju analize prethodnih revizija te daju očekivanja za sljedeće. Očekivanja od revizora sistematizirana su u dokumentu prema kojem je revizorsko društvo dužno sastaviti revizorsko izvješće o obavljenoj reviziji za potrebe HNB-a koje, među ostalim, mora sadržavati i informacije o provedenoj reviziji informacijskog sustava, kao i ocjenu stanja tog sustava i adekvatnosti upravljanja tim sustavom te bi trebalo kreditnoj instituciji i HNB-u pružiti kvalitetne i iscrpne informacije o rizicima kojima je taj informacijski sustav izložen. Pritom treba naglasiti da se ovaj dokument ne može smatrati formalnom metodologijom za obavljanje revizije informacijskih sustava kreditnih institucija. Naposljetku, valja naglasiti da HNB-ova očekivanja vezana uz obavljanje revizije informacijskih sustava imaju za cilj bolje razumijevanje uloga i odgovornosti kreditnih institucija i revizorskih društava u tom procesu. Temeljni su akti, odnosno relevantna područja za reviziju informacijskog sustava kreditnih institucija: Odluka o primjerenom upravljanju informacijskim sustavom (ožujak 2010.), Zakon o kreditnim institucijama (listopad 2008. + dodaci 74/09,153/09), Zakon o zaštiti osobnih podataka (lipanj 2003. + dodaci 118/06,41/08,130/11), Odluka o eksternalizaciji (zadnje siječanj 2010.), Odluka o upravljanju rizicima (zadnje ožujak 2010.), Odluka o sadržaju revizije u kreditnim institucijama (zadnje siječanj 2009.), Odluka o sustavu unutarnjih kontrola (zadnje ožujak 2010.). Osim gore navedene regulative, revizija se obavlja prema najboljim svjetskim praksama za upravljanje informacijskim sustavima i informacijskom sigurnošću kao što su: Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika (HNB, ožujak 2006.), CobiT ( Control Objectives for Information and related Technology ), ISO/IEC 27002:2005, ITIL/ISO 20000 ( Information Technology Infrastructure Library ). Dobra priprema jedan je od bitnih koraka u provođenju revizije informacijskih sustava termina kako plan ne bi bio većim dijelom premašen. Način na koji se IT procesi odvijaju i koliko se učinkovito odvijaju zavisi o postavljenim kontrolama, a one su i glavni predmet revizije. U prethodnom članku dan je pregled najpoznatijih standarda u području upravljanja informacijskim sustavom i kontrola koje ti standardi predlažu. U poslovnim procesima neke organizacije moguće je primijeniti istu logiku te je revizorov cilj identificirati postavljene kontrole te ih tijekom izvođenja revizije testirati. Testiranjem se utvrđuje jesu li kontrole osmišljene i implementirane kako je propisano regulativom, internim dokumentima te dobrim praksama u području upravljanja informacijskim sustavom, što često nazivamo testom dizajna kontrola. Provjera učinkovitosti kontrola se, s druge strane, radi kako bi se utvrdilo izvode li se implementirane kontrole učinkovito. Ako, primjerice, procedura izrade pričuvne kopije podataka zahtijeva dnevnu izradu pričuvne pohrane, na uzorku zapisa o izrađenim pričuvnim pohranama provjerava se jesu li ove aktivnosti i provedene. Uzorkovanje je posebna priča te je moguće napisati članak samo o tome. Revizija informacijskih sustava trebala bi se temeljiti na međunarodnim revizijskim standardima, što uključuje i pravilni postupak uzorkovanja. Nažalost, zbog čestog vremenskog pritiska, uzorkovanje se svodi na odabir manjeg broja transakcija odnosno zapisa koji se provjeravaju, što može dovesti do upitnosti rezultata revizije. Uzorkovanje, bilo ono metodološki precizno ili ne, ovisi o iskustvu i stručnosti revizora. Jednostavno, neki revizori imaju nos za pronaći probleme, pogotovo u situacijama gdje se ne primjenjuje metodološki pristup odabiru uzorka. Mučno čitanje rezultata A onda slijede muke po IT-u. U uvodnom je dijelu teme broja već rečeno da je današnji način poslovanja takav da ostavlja dosta mjesta za pogreške. Izuzmemo li namjerno zabušavanje ili prevare u informacijskom sustavu, revizor će često naći dosta materijala za izvještaj. Djelatnici jednostavno ne obave posao koji bi trebali, odnosno ne obave ga kako bi trebalo. Primjer su za to novi, tek uspostavljeni procesi koji će vjerojatno rezultirati nalazima provjere dizajna kontrola, ili ponavljajući poslovi koji nisu redovno nadgledani poput automatizirane izrade pričuvne pohrane podataka koja se već danima ne izvršava, a da to nitko nije primijetio. Iako se mnogi djelatnici mogu naći povrijeđeni nalazima revizije, u koju grupu spada i IT menadžment, rezultate revizije trebalo bi prihvatiti kao dobrodošlu pomoć pri unapređenju rada informacijskog sustava. Ovo je najlakše postići uz kontinuirano komuniciranje s IT djelatnicima konstruktivnim raspravama o uočenim problemima i definiranju prepo Tipovi revizije Revizija prve strane Revizija druge strane Revizija treće strane Ovdje se zapravo radi o internoj reviziji, kad je organizacija sama provodi ne bi li utvrdila je li implementirani sustav upravljanja IS-om sukladan zakonima, internim politikama, odnosno nekom od standarda (engl. first party audit). Glavni su razlozi za to izričiti zahtjevi samog standarda, želja visokog menadžmenta za učinkovitim sustavom, popravak bilo kakvih nesukladnosti prije dolaska ovlaštene certifikatorske kuće ili sistematično poboljšanje rada samog sustava. Reviziju druge strane (engl. second party audit) provodi organizacija nad svojim vanjskim partnerima (dobavljačima), a razlozi su uglavnom sljedeći: provjera, selektiranje i potvrđivanje vlastitih dobavljača; poboljšanje vlastitog sustava upravljanja IS-om preko poboljšanja sustava vanjskih partnera; povećanje uzajamne svijesti o važnosti sustava sigurnosti i sl. Nalazi takvih revizija često pomažu organizaciji u sklapanju novih ugovora i učvršćivanju već postojećih, temeljenih na povjerenju u siguran i efikasan rad druge organizacije. Revizija treće strane (engl. third party audit) nastala je kao rezultat sve većeg broja revizija druge strane, a ponajviše zahvaljujući povećanju interesa u područjima osiguranja kvalitete (engl. quality assurance) tijekom 1970-ih. Pojavila se potreba za osnivanjem nacionalnih i međunarodnih tijela koja bi zamijenila sve veće opterećenje tvrtkama u pogledu izvođenja revizija druge strane. Tako su nastali BSI i druge kuće: prvo kao nacionalne certifikatorske kuće, a potom i pod kapom međunarodnih organizacija, koje revizijama treće strane izdaju organizacijama certifikate usklađenosti s međunarodno dogovorenim standardima (npr. za ISO 27001). 68 studeni 2012. MREŽA

RevizoRSka je tuga pregolema ruka prije samog pisanja izvještaja. Ako se primijeni ovakav pristup, završni sastanak na kojem se prezentiraju nalazi revizije i daju očekivanja na odgovor menadžmenta postaje formalnost. Ako pak dođe do sukoba oko nalaza revizije, svaki bi nalaz trebao biti potkrijepljen formalnim dokazima koji objektivno dokazuju mišljenje revizora. Dokazi mogu biti u vidu raznih izvještaja, ispisa ekrana, poruka elektroničke pošte, ali i zapisnika sa sastanaka provedenih intervjua. Sukobi su tim manji što je revizor stručniji i ima više iskustva u samoj primjeni kontrola, a ne samo u teorijskoj podlozi za revizorski rad. Zadnji korak, koji se radi s vremenskim odmakom u odnosu na sve gore navedene aktivnosti, donosi provjeru provedbe predloženih preporuka te predstavlja reviziju u malom. Poznat pod tuđicom follow-up, obuhvaća sve aktivnosti kao i prava revizija, ali traje bitno kraće. Interne revizije često nemaju posebne i formalne follow-up revizije, već ih ugrađuju u sklopu svojih planiranih revizija tijekom godine. Smjer razvoja revizijskih metodologija Revizija informacijskih sustava kao proces je podložna konstantnim poboljšanjima, što se ogleda u više aspekata. Jednostavno provođenje intervjua u vidu pitanja putem checklista nadopunjuje se sve širom upotrebom alata za podršku reviziji. I dok je procesne kontrole relativno lako obuhvatiti razgovorom i pregledom dokumentacije i podataka, od revizora se očekuje da tehnički provjeri i konfiguracije IT opreme, ali i transakcijske podatke, što se bez upotrebe alata može pretvoriti u višednevni iscrpljujući rad. Osim podrške alata za provjeru specifičnih tehnologija, sve se češće upotrebljavaju i softverski alati za podršku procesu revizije. Ovi alati pružaju podršku aktivnostima planiranja, procjene rizika, upravljanja revizorskim timovima, automatskom kreiranju ispitnih lista, a da ne govorimo o uštedama u vremenu automatskog kreiranja revizorskih izvještaja na temelju unesenih podataka. Naravno, standardne funkcionalnosti arhiviranja i pretraživanja te statističkih rezultata također su podržane. Možda najznačajnije promjene u samim aktivnostima odnose se na primjenu tzv. kontinuirane revizije informacijskih sustava, koja pravi odmak u odnosu na tradicionalnu projektnu odnosno periodičku reviziju, kakvu danas susrećemo u svim tvrtkama. Kontinuirana revizija informacijskog sustava bazira se na uspostavi sustava indikatora ključnih rizika (KRI - Key Risk Indicators) koji se uspostavlja putem standardnih mehanizama nadzora informacijskih sustava (tzv. IT operation management alati) te kontinuirane procjene rizika. Odstupanja od definiranih veličina rizika daju signal da je potrebno provesti analizu odnosno reviziju problematičnog područja. Kako ovakav način revizije ima i nekih svojih nedostataka, trenutno se pokušava naći optimalni način rada koji bi dio spoj najboljih osobina jedne i druge metodologije. Certified Information System Auditor jedan je od poznatijih i priznatijih certifikata za revizore informacijskih sustava Ako pitate menadžment neke tvrtke o revizorima informacijskih sustava, većina će vam reći da su oni nužno zlo, zahtjev regulative koji jednostavno treba ispoštovati. Neki će dodati i da su smetala, odnosno dosadnjakovići koji samo usporavaju poslovne procese i prave dodatni trošak svojim nerazumnim preporukama. Dobar će im dio pridijeliti i termin nestručan odnosno nerazuman. Kad se sagledaju svi zahtjevi koji se postavljaju pred jednog revizora i osobine koje revizor mora imati da bi kvalitetno obavio posao, nije čudo da teško pada primanje gore navedenih epiteta i osjećaj smetanja u normalnom poslovanju neke tvrtke. A situacija je upravo suprotna. Premda je i posao revizora informacijskih sustava specijalnost sama za sebe, širina znanja i osobine koje je potrebno imati nadilaze mnoge druge poslove. Nije stoga čudo da za posao revizora informacijskih sustava već postoje i posebni studiji na našim fakultetima, a ne samo pojedinačni predmete. Ukratko, revizor informacijskih sustava mora dobro poznavati: Poslovanje u raznim sektorima - s obzirom na naše malo tržište, rijetko si koja tvrtka specijalizirana za reviziju informacijskih sustava može priuštiti revizore osposobljene za rad samo u jednoj grani industrije. Tako mnogi naši revizori rade i za financijske institucije, državne organizacije, proizvodne pogone i sl. Operativne procese u tvrtkama - kako se mnoge kontrole vežu uz tipične operativne procese u svim tvrtkama - poput pravne službe, kadrovske evidencije, robno-materijalnog knjigovodstva i sl. - prethodno iskustvo rada u nekim od tih aktivnosti poželjno je radi boljeg razumijevanja primijenjenih kontrola u njima. Specifičnu regulativu - revizori informacijskih sustava praktički moraju biti mali pravnici. Naime, dobar se dio preporuka veže uz kontrole informacijskog sustava koje nisu u skladu sa zakonima RH, regulativom vezanom uz pojedini poslovni sektor, ugovorne obveze s dobavljačima i kupcima, zahtjeve nad izvještajnim sustavom, industrijske standarde i zahtjeve i još mnogo toga. Rizike informacijskog sustava - jedno je istraživanje pokazalo da menadžment ne želi revizorska izvješća koja će govoriti da su primijenjene kontrole neučinkovite, već rizike i utjecaj koji pogreške informacijskog sustava mogu imati na poslovanje tvrtke. Stoga je revizorima posebno važno razumjeti vezu između loše implementiranih kontrola i rizika do kojih one dovode. Tehničko znanje o ICT-u - revizor mora dobro razumjeti informacijsko-komunikacijske tehnologije, uključujući hardver i softver, jer bez toga ne može razumjeti rizike informacijskog sustava. Danas je na tržištu prisutan golem broj hardverskih i softverskih proizvoda i često se revizor mora detaljnije upoznati s onima primijenjenima u revidiranom subjektu. Sigurnosne kontrole i dobre prakse razvoja i održavanja informacijskih sustava - ovo je srž revizije informacijskih sustava. Informacijski se sustav revidira u odnosu na brojne standarde i dobre prakse rada informacijskog sustava. Ovi su zahtjevi obrađeni u posebnom članku ove teme broja. Međunarodni revizorski standardi - revizija informacijskih sustava kompliciran je proces sâm za sebe, s brojnim zahtjevima, od kojih su mnogi zadani i ne smiju se zanemariti. Dobro je da revizor posjeduje neki certifikat ili drugi pismeni dokaz o poznavanju standarda revizorskog posla. CISA (Certified Information System Auditor) jedan je od poznatijih i priznatijih certifikata u tom području. Osim poznavanja gore navedenih područja, uspješan revizor mora imati i osobine dobrog organizatora/planera, upravljanja vremenom, uljudnosti i strpljenja, objektivnosti, preciznosti u pisanju bilješki i izvješća, principijelnosti i sl. MREŽA studeni 2012. 69

Revizija informacijskih sustava Alati za podršku reviziji Revizija informacijskog sustava neće dati dobre rezultate ako samo šetamo po IT odjelima s papirom u ruci i olovkom u džepu. Za otkrivanje stvarnih problema morat ćemo u pomoć pozvati posebne alate Nedavno ste u Mreži mogli pročitati članak o CAAT alatima (Computer Assisted Audit Tools). Ovi se alati koriste pri obradi većeg broja transakcija odnosno podataka i vrlo su korisni pri revizorskom radu jer ukazuju na moguće propuste i prevare u velikom broju podataka te povećavaju kvalitetu uzoraka na kojima revizori testiraju primijenjene kontrole u informacijskom sustavu. Premda postoje i verzije otvorenog koda, komercijalne verzije koje uglavnom možemo naći u dobro strukturiranim i opremljenim revizorskim organizacijskim jedinicama prilično su skupe pa ih samim tim i ne koriste svi. No ta grupa CAAT alata nisu jedina softverska pomagala koja olakšavaju revizorski posao. Zapravo, moguće je kategorizirati alate za pomoć reviziji informacijskih su stava u više grupa, prvenstveno po glavnoj funkciji koju obavljaju. Tako se CAAT alati u užem smislu smatraju alatima koji s pomoću velikog broja statističkih i matematičkih modela i tehnika ukazuju na sumnjiva razilaženja u podacima. Ovi se alati često zovu i GAS alatima (Generalized Audit Soft ware). S druge strane imamo alate koji pronalaze ranjivosti u određenim tipovima softvera, odnosno daju preporuke za očvršćivanje konfiguracija operacijskih sustava, baza podataka, poznatih softverskih proizvoda i sl. U ovu grupu svakako možemo ubrojiti i alate za provjeru ranjivosti o kojima je već bilo riječi na stranicama ovog časopisa, ali i alate za penetracijska testiranja. Treću grupu čine alati za automatizaciju procesa revizije koji na strukturirani način obrađuju podatke planiranja, pripreme, izvođenja i izvještavanja o revizijskim projektima, a koriste ih veće organizacijske jedinice interne revizije, odnosno konzultantske tvrtke specijalizirane za obavljanje poslova revizije. O ovim se alatima malo zna i govori, ali njihovo je tržište sve veće i ima ih sve više (v. okvir). Revizija mrežnih postavki Ako ostavimo po strani testiranje dizajna tipičnih IT procesa za koje su nam uglavnom dovoljne checkliste, odnosno olovka i papir iz uvoda ovog članka, pozabavimo se testiranjem četiri osnovne grupe informacijske imovine za koje si možemo pomoći raznim dodatnim alatima i tehnikama. Prva se odnosi na provjeru postavki interne računalne mreže, koja je ujedno i prva obrambena linija do poslovnih podataka koji se nalaze u bazama podataka. Iako je o mrežnoj sigurnosti moguće napisati cijelu knjigu, navedimo najvažnije stvari koje je potrebno provjeriti u ovoj domeni. Kako je mreža svake tvrtke povezana s ostatkom svijeta zbog kori Primjer dijela SQL skripte koja testira račun pod kojim su pokrenuti MS SQL servisi CREATE TABLE #user (value VARCHAR(50), data VARCHAR(50)) IF (charindex(\,@@servername)=0) INSERT #user EXEC master..xp_regread HKEY_ LOCAL_MACHINE,SYSTEM\CurrentControlSet\Services\ MSSQLSERVER,ObjectName ELSE BEGIN PRINT Note: SQL Server was determined to be a named instance PRINT DECLARE @RegistryPath VARCHAR(200) SET @RegistryPath = SYSTEM\CurrentControlSet\ Services\MSSQL$ + RIGHT(@@SERVERNAME,LEN(@@SERVERNAME)- CHARINDEX(\,@@SERVERNAME)) INSERT #user EXEC master..xp_regread HKEY_LOCAL_ MACHINE,@RegistryPath,ObjectName END SELECT TOP 1 DATA AS [SQL Server Service Account] FROM #USER IF (SELECT TOP 1 DATA FROM #user)=localsystem BEGIN PRINT PRINT SEVERITY: High PRINT PRINT DESCRIPTION: LOCALSYSTEM AUTHORITY being used for SQL Server service account is not recommended. PRINT PRINT SOLUTION: To change the MSSQLServer Service Account: PRINT 1. Right-Click My Computer and select Manage from the drop down menu. PRINT 2. Double-click the Services icon. PRINT 3. Select the MSSQLServer service. PRINT 4. Click the Startup button. PRINT 5. Change the Log On As option. PRINT END DROP TABLE #user PRINT 70 studeni 2012. MREŽA

štenja servisa elektroničke pošte i Interneta, a mnoge druge prezentiraju i dio svojih poslovnih podataka putem web stranica, internetskog bankarstva, elektroničkih trgovina i sl., jasno je da je potrebno posebnu pažnju posvetiti centralnoj točki te veze, a to su centralni usmjernik i vatrozid. Prilikom revizije svakako treba pogledati pravila dozvoljenog prometa, provjeriti postavljenu arhitekturu mreže (segmentacija) te postavke bilježenja zapisa spajanja odnosno mrežnog prometa. Za provjeru segmentacije mreže možemo se poslužiti i naredbama alata NMap, koji će nam dati i popis otvorenih portova odnosno servisa na opremi spojenoj na mrežu. Uobičajeno je izbjegavati nešifirane protokole prijenosa podataka te koristiti verzije koje kriptiraju promet kao što su SFTP, HTTPS i sl. Neki standardi, poput PCI DSS-a, posebnu pažnju posvećuju bilježenju zapisa odnosno logova koje bi trebalo periodički provjeravati te arhivirati kako bi mogli poslužiti kao forenzički materijal u slučaju incidenata. Često ovu funkciju preuzimaju posebni hardverski i softverski alati namijenjeni baratanju velikom količinom podataka te proširuju funkcije vatrozida. Kad govorimo o segmentaciji mreže, danas je uobičajeno da se postavljaju stroga pravila mrežnog prometa između raznih zona, pa su tako uobičajene zone odnosno segmenti Demilitarizirana zona, u koju se najčešće stavljaju poslužitelji web stranica, elektroničke pošte i primjerice javni FTP poslužitelj; zatim segment poslovnih poslužitelja kojemu pristup imaju samo administratori sustava, ali ne i obični korisnici (tzv. management zone) te segmenti radnih stanica običnih korisnika. S obzirom na veliku količinu podataka na mrežnoj opremi koju je potrebno obraditi, teško je očekivati da djelatnici konstantno nadziru mrežni promet te se očekuje da se funkcije vatrozida obogate i upotrebom IDS i IPS sustava, koji će brže reagirati na moguće napade i neuobičajene aktivnosti mrežnog prometa. Očvršćivanje operacijskih sustava Današnji operacijski sustavi uvelike nadilaze osnovne funkcionalnosti koje su u povijesti bile vezane uz njih. Naime, operacijski sustav čini vezu između hardvera Komercijalni alati za automatizaciju procesa Upravljanje revizijskim procesom Automatizacija papirologije Kontinuirana revizija Alati za samoprocjenu Statistička analiza podataka Detekcija i prevencija prevara Vrednovanje sustava unutarnjih kontrola AlineGRC, ACL, auditol, AutoAudit, BPS Resolver s Audit Solution, BWise GRC, CCH TeamMate, Compliance360, Galileo Audit System, GRC on Demand, Methodware ERA, MetricStream, Protiviti s Governance Portal, RSA Archer egrc Suite AlineGRC, auditol, AutoAudit, BWise GRC, CCH TeamMate-EWP, Galileo Audit System, GRC on Demand, Methodware ERA, MKinsight, Pentana AuditWork System, policyiq, Protiviti s Governance Portal, RSA Archer egrc Suite Approva, ACL, Caseware Monitor, BWise GRC, Compliance360, WizRule, eprocessmanager, IDEA, MetricStream AlineGRC, AutoAudit, BWise GRC, GRC on Demand, Methodware ERA, MKinsight, policyiq, Protiviti s Governance Portal ACL, WizRule, IDEA, SEC-Qure Q Software ACE, Approva, ACL, Caseware Monitor, FirstStrike Fraud Detect, IDEA, SEC-Qure Q Software, AlineGRC, Approva, AutoAudit, BPS Resolver s Internal Control Solutions, BWise GRC, Caseware Monitor, eprocessmanager, GRC on Demand, Methodware ERA, MKinsight, Protiviti s Governance Portal, RSA Archer egrc Suite Kako bismo vam olakšali traženje alata za pomoć u reviziji informacijskih sustava, evo jedne liste koju je objavio poznati časopis Internal Auditor. Recenzirani alati svrstani su u kategorije koje čine ključne funkcionalnosti revizijskog posla. Ovo je napravljeno zbog činjenice da je alate teško svrstati samo u jednu kategoriju revizorski alati te se neki pojavljuju u više kategorija. Polazeći od vaših želja i fokusa na pojedinu funkcionalnost, lakše se usmjeriti na pojedine alate. Imajte samo u vidu da mnogi od ovih alata koštaju pravo malo bogatstvo. Upravljanje revizijskim procesom pružaju podršku za aktivnosti planiranja revizije, izrade upitnika, organizaciju revizorskog tima, arhiviranje rezultata i izradu izvještaja. Automatizacija papirologije sustavi upravljanja dokumentacijom (DMS) posebno prilagođeni za dokumentaciju koja nastaje u revizorskom procesu. Kontinuirana revizija podrška kontinuiranom načinu revizije informacijskih sustava (v. detaljnije prethodni članak). Alati za samoprocjenu pružaju mogućnost da djelatnici sami vrednuju kontrole. Statistička analiza podataka CAAT alati u užem smislu. Obrađuju velike količine podataka i statističkim i matematičkim modelima traže nelogičnosti i moguće prevare u podacima. Detekcija i prevencija prevara Slično kao prethodna kategorija, ali imaju razrađene modele i tipične scenarije prevara koje je moguće detektirati putem raznih agenata nad informacijskim sustavom. Vrednovanje sustava unutarnjih kontrola Alati za provjeru sustava usklađenosti s postavljenim sustavom unutarnjih kontrola. Često imaju baze znanja s kontrolama svjetski poznatih standarda i regulative. i djelatnika te predstavlja drugi sloj obrane naših poslovnih podataka. Operacijski sustavi više nisu samo skup upravljačkih programa (drivera), upravljanja datotečnim sustavom i upravljanja resursima. U sklopu instalacije operacijskog sustava danas je uobičajeno naći i web preglednike, web aplikacijske poslužitelje, imeničke servise i sl. koji svaki za sebe unose mnoge nove ranjivosti i postavke koje je potrebno provjeriti. Ako upotrebljavamo alate za pomoć reviziji, ovdje je zgodno primijeniti alate za provjeru ranjivosti koji manje-više ispituju ranjivosti većeg broja operacijskih sustava, kako Windowsa tako i Unix-baziranih. Prolazeći kroz CVE bazu ranjivosti lako ćemo saznati koji poslužitelj nema instaliranu najnoviju kritičnu zakrpu, koji problematični servisi rade na pojedinom poslužitelju, pa čak i koja opcija operacijskog sustava nije podešena po preporučenim dobrim praksama. Ako revidiramo Windows okolinu, svakako je preporučljivo pokrenuti DumpSec ili neki sličan alat koji će nam olakšati posao pronalaska mrtvih djelatnika koji još imaju aktivne račune, čija zaporka nije u skladu s propisanom politikom ili koji možda čak nemaju ni postavljenu zaporku! Osim ovog alata, moguće je koristiti i alate za provjeru konfiguracije računala koji nam mogu otkriti probleme s kapacitetima memorije, procesora ili diskova. Baze podataka Kad je riječ o bazama podataka, dio alata za provjeru ranjivosti može naći i probleme za najpoznatije sustave upravljanja bazama podataka. Tako svi poznatiji alati za provjeru ranjivosti pronalaze nedostatke primjene kritičnih zakrpa za MS SQL Server, Oracle, MySQL i druge važnije proizvode iz ove skupine. Bez obzira na njih, dobro je naći posebne skripte za svaku bazu koju provjeravamo ili napisati svoju osobnu, ako dovoljno dobro MREŽA studeni 2012. 71

Revizija informacijskih sustava poznajemo SQL jezik i sâm proizvod. Ove skripte često koriste upite nad metapodacima baze, odnosno nad sistemskim tablicama kako bi pronašle konfiguracije koje nisu u skladu s dobrim praksama. Tako, primjerice, za MS SQL Server proizvode treba provjeriti jesu li ugašene demo baze kao što su Northwind i Pubs; koja je korištena login metoda; postoje li korisnički računi bez zaporke; kako su podešene audit postavke nad podacima i sl. Revizija aplikativnih kontrola Poslovnim se podacima barata putem poslovnih aplikacija bilo da su one kupljene kao standardni proizvod neke tvrtke ili razvijene posebno za određenog kupca. Za gore spomenute tri grupe informacijske imovine lako je naći tehnike revizije ili u literaturi ili na raznim stranicama na Internetu. Kada je riječ o reviziji pojedinačnih aplikacija, pogotovu onih posebno razvijenih za određenog kupca, moramo se poslužiti generičkim provjerama koje ćemo prilagoditi za svaku revidiranu aplikaciju. Ove generičke provjere često nazivamo testiranjem aplikativnih kontrola. Što je, dakle, potrebno provjeriti kod svake aplikacije? Jedna je od bitnih stvari provjera sučelja za ulazne i izlazne podatke. Ako kontrole nisu dovoljno dobro postavljene, moguće je da baza s vremenom sadrži mnoštvo nekonzistentnih podataka, a ni rušenja sustava tada nisu rijetka pojava. Primjer je za to mogućnost upisa slova u polja za unos iznosa, unosa nevaljanih datuma, unosa dvostrukih podataka koji bi inače trebali biti jedinstveni i sl. S druge strane, nedovoljno testiranje rezultata, odnosno nekorištenje raznih hash i total funkcija, može dovesti do pogrešno prezentiranih izvještaja. Provjera kompletnosti odnosno cjelovitosti transakcije još je jedna u nizu provjera potrebna kako bi se izbjegli nekonzistentni podaci u bazi. Velik broj transakcija u poslovnim aplikacijama nije jednostavan upis u bazu, već se one često sastoje od niza manjih aktivnosti upisa u više tablica, pri čemu je bitno osigurati da se sve te aktivnosti odviju u potpunosti. Najbolji je primjer za to prijenos novca s jednog računa u banci na drugi. Radi se o transakciji pri kojoj se na jedan račun mora upisati željeni iznos, a s drugog skinuti taj isti iznos. Lako je pretpostaviti što bi se dogodilo u slučaju da se izvrši samo jedna od tih aktivnosti. Kad testiramo aplikativne kontrole, osim gore navedenih, potrebno se dotaći i testiranja učinkovitosti kontrola tipičnih IT procesa vezanih uz rad s aplikacijama. Tako ćemo testirati prava pristupa funkcijama aplikacije odnosno dobre prakse vezane uz segregaciju dužnosti rada po pojedinim modulima ili aktivnostima aplikacije, proces upravljanja promjenama nad revidiranom aplikacijom, kao i proces upravljanja konfiguracijama i pričuvnom pohranom. Što koriste revizori? DumpSec Možemo ga već nazvati i djedicom među alatima jer postoji već jako dugo, a koristi se za ispis pristupnih listi i sigurnosnih postavki datotečnog sustava, registryja, pisača, dijeljenih diskova i sl. u strukturiranom formatu, i to još Windowsa NT. Praktički je nezamjenjiv u otkrivanju pogrešaka uporabe politike zaporki jer daje podatke o isteklim zaporkama, onima koji nisu u skladu s Group Policyjem, zadnjoj prijavi na sustav i mnogim drugima. U revizijama ga često preporučujem kao alat koji bi trebao postati sastavni dio operativnih poslova informatike. Nmap Nezaobilazan alat za otkrivanje aktivne mrežne opreme i osnovnih postavki mrežnih servisa. Iako u osnovi komadnolinijski alat, danas već postoje mnoga lijepo dotjerana grafička sučelja koja čine rad s alatom dostupnim i slabijim poznavaocima tematike mrežne sigurnosti. Daje popis pokrenutih poslužitelja na mreži, otvorenih portova, servisa i sl. Alati za provjeru ranjivosti Ovdje ćemo strpati sve alate ovog tipa počevši od dobro poznatog Nessusa, koji više nije besplatan, ostalih komercijalnih alata poput Retine, QualysGuarda, Microsoft Baseline Security Analyzera, Nexposea i sl. Da se ne uvrijede drugi nespomenuti alati, svi oni dobro obavljaju funkciju otkrivanja ranjivosti postavljenih konfiguracija raznih tipova softvera, od operacijskih sustava, baza podataka, poznatog middlewarea i sl. Rezultati pokrenutog skeniranja uglavnom su uparivi s općeprihvaćenom bazom ranjivosti informacijskih sustava CVE koju održava CVE Numbering Authority. ZenMapGUI - jedno od grafičkih korisničkih sučelja za NMap Nexpose Community Edition mercedes je među besplatnim alatima za provjeru ranjivosti Provjerite politiku zaporki alatom DumpSec 72 studeni 2012. MREŽA