Prezentacije u travnju

Ovaj mjesec sudjelujem u radu dviju stručnih konferencija u Hrvatskoj, gdje ću i održati prezentacije.

Od 11. do 13.4.2019. sudjelujem na konferencije Hrvatskog instituta internih revizora u Lovranu. Tamo ću 12.4. održati prezentaciju "Kako nam analitički alati mogu pomoći u otkrivanju i sprečavanju prijevara?". Govoriti ću o analitičkim tehnikama koje se koriste u detekciji fraud-a, a prezentaciju ću ilustrirati primjerima korištenja alata CaseWare IDEA u takvim scenarijima.

Više o samoj konferenciji možete doznati na službenoj stranici.

U utorak, 30.4.2019. sudjelujem u radu konferencije DataFocus 2019, koju organizira tvrtka INSig2. Ova, sada već tradicionalna konferencija, bavi se računalnom forenzikom. Naslov moje prezentacije je  "Forenzička analiza cyber incidenata", a govoriti ću o metodologiji forenzičke istrage cyber/kibernetičkih incidenata, s osobitim naglaskom na napredne tehnike napada.

Više o samoj konferenciji možete doznati na stranici tvrtke INSig2.

Pozivam sve one koji još imaju otvorene termine u kalendaru neka se pridruže ovim konferencijama. Također, sudionici prezentacija se mogu javiti i nakon vremenskog okvira predviđenog za prezentaciju kako bi nastavili diskusiju o otvorenim temama. Oni koji nisu u mogućnosti sudjelovati na ovim konferencijama mogu zatražiti materijal mailom.

Radujem se našem susretu.

Borea na stručnim konferencijama

Idući tjedan održati ću prezentacije na dva stručna skupa. Ukoliko imate priliku sudjelovati na ovim konferencijama, pozivam vas na diskusiju i izmjenu iskustava po održavanju prezentacija. Ukoliko niste u mogućnosti sudjelovati, javite se pa ću vam proslijediti prezentaciju.

Prva konferencija je DataFocus 2013, koja se bavi računalnom forenzikom i digitalnim dokazima. Konferencija će se održati u utorak 9.4.2013., a organizira je tvrtka INsig2 s kojom surađujem niz godina. Tema moje prezentacije je nedavno usvojena međunarodna norma ISO/IEC 27037 kojom se daju smjernice za provedbu postupka identifikacije, prikupljanja, akvizicije i očuvanja digitalnih dokaza. Ovaj postupak, koji prethodi samoj forenzičkoj analizi digitalnih dokaza, ima ključnu ulogu u osiguranju vjerodostojnih, detaljnih i kompletnih digitalnih dokaza, pa tako direktno može utjecati na uspješnost forenzičke analize i ispravnost pravne odluke.

Druga konferencija na kojoj ću, sada već tradicionalno, sudjelovati je godišnja konferencija Hrvatskog instituta internih revizora (HIIR). Ovo je već peta konferencija HIIR-a, a ove godine se održava u Zadru u četvrtak 11.4.2013. Prezentacija će biti održana u okviru tema koje se bave računalnom sigurnosti i interne revizije IS-a. Tema prezentacije je penetracijsko testiranje koje se predstavlja sa specifične pozicije relevantne za unutarnju reviziju informacijskog sustava.

Karika koja nedostaje

Magazin Banka u broju od kolovoza pod ovim naslovom donosi moj članak o reviziji informacijskih sustava. BANKA_8-12_DP

Hrvatski Enron - po drugi put

Kako javlja današnji tisak, na WikiLeaksu je izašla poruka američkog veleposlanika u Zagrebu iz veljače 2010. U toj poruci on prepričava svoj razgovor s državnim odvjetnikom Bajićem, a jedna od tema je bila i Podravka.

Tekst dijela poruke:

(C) Bajic has said privately that Podravka could be Croatia’s Enron, a game-changing case in the GoC’s efforts to tackle corruption, particularly if he can obtain sufficient evidence that Polancec intentionally undersold XXXXXXXXXXXX. Cooperation with Hungarian prosecutors continues to improve. Bajic said he was very impressed with the evidence and analysis the Hungarians provided on the XXXXXXXXXXXX connection.


S zadovoljstvom sam primjetio da je državni odvjetnik opisujući veleposlaniku aferu Spice koristio termin "Hrvatski Enron", a kako sam ja na ovim stranicama opisao istu aferu u listopadu 2009. Još nam ostaje vidjeti hoće li ovaj slučaj rezultuirati istim strukturnim pomacima kao svojedobno i Enron. Moglo bi se pokazati da neki i od velikih međunarodnih igrača nisu baš bili sasvim nevini u ovom slučaju (kao što nisu bili ni kod Enrona).

Inače, gornji citat je primjer filtriranja poruka prije nego što su postale dostupne na internoj mreži američke Vlade a potom i na WikiLeaksu (primjetite XXXXXXX u tekstu, to se možda odnosi na neku osobu ali i na neku institciju/kompaniju - bilo bi zanimljivo saznati o kome se radi). O ovome sam pisao u prethodnom tekstu o WikiLeaksu.

Također, nisam siguran da će link na jednu od replikacija WikiLeaksa koji navodim u uvodu biti živ u trenutku kada budete ovo čitali, no vjerujem da ćete pronaći ovaj "telegram" na drugim stranicama.

Sudjelovanje na drugoj konferenciji Hrvatskog instituta internih revizora

Idući tjedan, od 25. do 27.03. 2010. u Opatiji se održava druga konferencija Hrvatskog instituta internih revizora. U petak drugog dana konferencije sudjelovati ću u radu sekcije koja se bavi sigurnošću informacijskih sustava. Tema moje prezentacije su sigurnosni incidenti i uloga internih revizora u uspostavi procesa praćenja sigurnosnih incidenata.

Sigurnosni incidenti su siva zona informacijske sigurnosti. Naše tvrtke u zadnjih nekoliko godina pokazuju porast zanimanja za organizacijski aspekt informacijske sigurnosti, sve više se govori o različitim radnim okvirima (a pomalo se ovi okviri i primjenjuju), interna revizije se sve ozbiljnije suočava s ovom problematikom... Istovremeno, o sigurnosnim incidentima, naročito onima koji se manifestiraju u kategorijama povjerljivosti i cjelovitosti, još uvijek se premalo zna. Glavni razlog ove ignorancije leži u nedostatku i manjkavostima procesa sigurnosnog nadzora nad radom informacijskog sustava. Rezultat: o informacijskim rizicima vlada bolja slika nego što ona (možda) treba biti, nedostaje komponenta povjesnog pogleda na mnoge računalne prijetnje.

Uloga IT revizora je dvojaka. Prvo, IT revizori svakako moraju biti među pokretačma inicijative za uspostavu procesa praćenja sigurnosnih incidenata. Drugo, IT revizori mogu (pa i moraju) i sudjelovati u postupku rješavanja ovih incidenata, naravno u okvirima svojih nadležnosti.

Vidimo se u Opatiji.

Hrvatski Enron

Je li slučaj Podravska hrvatski Enron (zanemariti ću, za potrebe ovog napisa, politički kontekst ove afere)?

Sličnosti su brojne. U oba je slučaja protagonist akcije bio management ovih tvrtki. U oba slučaja možemo govoriti o izvedbi sofisticiranog poslovno-financijskog scenarija, čiji je autor u slučaju Podravke za sada nepoznat. Istina, u slučaju Enrona vidjeli smo netočno uljepšavanje poslovnih rezultata na temelju kojeg je management ostvario nezasluženu korist. U slučaju Podravke imamo pokušaj preuzimanja tvrtke, kao i činjenicu da su se u stvarnosti provele konkretne financijske transakcije među različitim subjektima, a ne tek knjigovodsveno friziranje. No, pohlepa je pokretač u oba slučaja. Na koncu, i u slučaju Enrona bilo je govora o političkim pokroviteljima cijele operacije.

No, ako je generalna usporedba s Enronom održiva, možemo li, vezano na temu ovog bloga, govoriti o posljedicama slučaja Podravka na informacijske tehnologije (na koju su Enron i SOX koji je slijedio iza Enrona, itekako utjecali)?

Na prvi pogled, teško da možemo govoriti o vezi slučaja Podravke i informacijskih tehnologija. U operaciji Spice je informacijska tehnologija bila tek poslovni okvir, a politika se pokazala bitnijim faktorom. Ova je procjena osobito važna ako pokušamo identifcirati ulogu koju je revizija trebala odigrati u sprječavanju cijele operacije.

No, treba reći je revizija poslovnih podataka veoma lako mogli utvrditi indikatore problematičnih financijskih transakcija. S druge strane, moglo bi se pretpostaviti da revizija nije mogla utvrditi točno stanje jer su rezultati unutar informacijskog sustava bili modificirani ili prikriveni, no, realno gledajući, ne vjerujem da se to desilo. Naprosto, ublaženim riječima, od revizije nitko nije tražio informaciju o sumnjivim transakcijama.

Drugim riječima, cijeli je slučaj mogao biti preduhitren izvještajima revizora, no očigledno nije bilo (političke) volje za takvim izvještajima.

Stoga, bez obzira na prisutnost političkog konteksta cijele afere, jedna od pouka morala bi ići u smjeru jačanja uloge revizije, pri čemu treba posebno značenje dati i reviziji informacijskih sustava (da se spriječe i moguće sofisticirane modifikacije poslovnih podataka). Svatko tko je imalo upućeniji u ulogu revizije u poslovanju naših tvrtki može posvjedočiti da revizija općenito, a posebno i IT revizija, ima status nužnog zla a ne korektivnog mehanizma upravljanja poslovnim procesom.

Zapravo, umjesto usporedbe s Enronom, možda bi slučaj Podravka bilo bolje nazvati nazvati Riječkom bankom ne-financijskog sektora. No, hoće li netko biti spreman pokrenuti mjere koje je svojedobno, nakon slučaja Riječke banke, pokrenula HNB?

Revizija u razdoblju pohlepe

Jedna od tema koje rado opisujem na ovim stranicama su slučajevi insajderskog računalnog kriminala. Pri tome obrađujem publicirane i, uglavnom, inozemne slučajeve (što naravno uopće ne znači da i mi nemamo konje za trku).

Najfriškiji i veoma ilustrativan primjer vezan je za posrnulu indijsku outsourcing tvrtku Satyam. Za neupućene, Satyam je jedan od najvećih primjera korporativne prijevare u posljednje vrijeme. Na naslovnice su izbili početkom godine, kada je utvrđeno da su u duljem razdoblju iskazivali napuhane poslovne rezultate. Klupko se počelo razmotavati nakon prošlogodišnjih sumnjivih poslovnih poteza kojima su izazvali dioničare.

Neću ulaziti u financijske detalje same prijevare, više o možete naći na ovoj stranici. Za nas priča počinje izvještajem o analizi ovog slučaja koji je objavljen početkom ovog tjedna. Kako javlja InformationWeek, Satyam je generirao oko 7.500 lažnih faktura klijentima čime je poslovne rezultate pokazao znatno boljim nego što su bili (i što je naravno utjecalo na cijenu dionica ove tvrtke). Za ove stranice je osobito zanimljiv način generiranja ovih faktura: Satyam (ponavljam još jednom - IT outsourcing firma sa 40.000 zaposlenih, a razvoj aplikacija im je jedna od središnjih kompetencija) nedozvoljeno je modificirao vlastite poslovne aplikacije i omogućio kreiranje lažnih faktura ali tako da njihovo postojanje ne izazove sumnju i tako da budu izdvojene od realnih transakcija (pogađate zašto: lažne fakture nisu nikad bile naplaćene). Na taj način je prikazan prihod od 946 milijuna USD.

Ovaj slučaj je dobar primjer kojim revizori uvijek mogu opravdati svoje inzisitranje na reviziji postupka upravljanja aplikativnim promjenama, što se često smatra dosadnim inzistiranjem na formalnim detaljima. Naime, veoma je teško provesti striktnu kontrolu procesa upravljanja promjenama. Mjere mogu biti presložene za manje i srednje organizacije (izolacija razvojne, testne i produkcijske okoline; zaštita programskih biblioteka; stroga definicija i dodjela korisničkih prava; odvajanje pristupnih privilegija; formalna procedura...), što i za velike organizacije često predstavlja ograničenje.

No, ovaj slučaj pokazuje i nedostatke same revizije provedene u Satyamu.

Prvi nedostatak se odnosi na reviziju procesa upravljanja promjenama u Satyamu. Ne znam koliko je detaljno napravljena revizija ovog procesa, no kada se ovakva prijevara dogovori na najvišoj razini i kada je u scenarij uključeno više ljudi s odgovarajućim pravima (a očigledno je da je u Satyamu bio takav slučaj), onda redovita revizija općih kontrola IS-a teško može dati rezultate.

Druga revizorska greška se zapravo pokazala ključnom: revizor je propustio, a svakako je morao, utvrditi da 7.500 faktura nije pokriveno prihodom na računu u banci.

Granica između financijske revizije i revizije informacijskih sustava je, govoreći rječnikom politike, veoma meka. Poznavanje i jedne i druge strane medalje je neohodno za uspjeh revizije.

No, ipak treba reći da je prijevara u Satyamu ponajprije bila omogućena pohlepom i prividnim dobrim rezultatima koji su, uostalom kao i u drugim segmentima ali u istim vremenima, zasigurno spriječili dioničare da na vrijeme pogledaju istinu.

Obnova kontinuiteta

Prije svega, dugujem ispriku stalnim čitateljima ovih stranica. Prošlo je puno vremena od zadnjeg teksta na ovim stranicama. Nisam, naravno, izgubio polet, već sam bio prilično zaokupljen na nekoliko projekata, pa su ove stranice, nekako, završile u drugom planu. Uskoro će biti nešto više riječi o ovim projektima, a posebno ću opisati rad na razvoju aplikacije za upravljanje informacijskim rizicima. Osim na projektima, sudjelovao sam i u nekoliko događaja i javnih skupova. Krajem veljače sam na redovitim mjesečnim sastancima hrvatskog ogranka ISACA-e predstavio metodu za upravljanje rizicima - MEHARI, a u najfriškijem sjećanju je i prošlotjedno sudjelovanje na prvoj konferenciji internih revizora u Opatiji, u organizaciji Hrvatskog instituta internih revizora. HIIR je, pored hrvatskog ogranka ISACA-e, jedina stručna organizacija koja se, među ostalim, bavi i revizijom informacijskih sustava.

Glavnu riječ u planiranju, organizaciji, a naročito vođenju stručnog programa konferencije u Opatiji imali su sami revizori. Organizacijski dio nije nimalo podbacio, a stručni dio bio je osobito zanimljiv, naročito onaj koji se odnosio se na reviziju informacijskih sustava.

Borea je održala jednu veoma zanimljivu i dobro posjećenu radionicu o korištenju CAATT alata IDEA. Radionica se bazirala na stvarnom primjeru iz poslovne prakse i u, preko 120 minuta, predstavili smo glavne analitičke mogućnosti softvera IDEA.

Također, održao sam i prezentaciju koja se odnosila na jedno od najpodcjenjenijih područja informacijske sigurnosti - upravljanje log zapisima. Ova tematika podjednako je zanimljiva i stručnjacima za sigurnost kao i revizorima informacijskih sustava. Revizorima je zanimljiva iz dva razloga. Prvo, revizija svakog imalo osjetljivijeg informacijskog sustava mora uključivati i reviziju procesa upravljanja log zapisima. Drugi razlog leži u činjenici da log zapisi sadrže brojne informacije o radu i korištenju informacijskog sustava. Ove informacije se moraju svakako sagledati u situacijama kada se izvodi detaljna analiza pojedinih sigurnosnih mjera odnosno kada se testira provedba predviđenih postavki.

Konferencija u Opatiji pokazala je veliko zanimanje za problematiku revizije informacijskih sustava, što nimalo ne čudi s obzirom na sve prisutnije regulatorne zahtjeve. Raduje što su sudionici konferencije bili spremni podijeliti svoja razmišljanja u ovom dijelu struke koje se, u našem okruženju, tek treba etablirati.

RiskAudit i revizija informacijskih sustava

Revizija informacijskih sustava je česta tema ovih zapisa. O IT reviziji se može govoriti prilično uopćeno, a takav je, veoma često, i način percepcije revizije informacijskih sustava u našim tvrtkama. No, IT revizija postaje realnost i obaveza. Upravo iz tog razloga je Borea obnovila i redefinirala poslovnu uslugu RiskAudit. Ova se usluga u svojoj prvoj fazi primjene odnosila na opću procjenu sigurnosti informacijskog sustava. Uključivala je i tehničke i organizacijske sigurnosne mjere, model primjene podrazumijevao je sporadične provjere na incijativu IT odjela, a rijetko uprave ili interne revizije. No, s obzirom da i kod nas dolaze vremena kada će se o reviziji informacijskog sustava početi razmišljati na sustavan način (vrijedni izuzeci već razmišljaju na takav način), Borea je prilagodila model provedbe poslovne usluge RiskAudit zahtjevima interne revizije. Glavni cilj je pružiti pomoć tvrtkama koje nemaju vlastite timove revizora informacijskih sustava ili takvi timovi nisu dovoljno ekipirani. RiskAudit se može izvoditi prema "outsourcing" modelu – dakle kao potpuni proces revizije informacijskog sustav – ili prema "co-sourcing" modelu – pružanje parcijalne pomoći postojećim timovima za IT reviziju.

Nedavno sam odgovarao na pitanje u čemu je razlika između "security assessment-a" (RiskAudit prema prethodnoj definiciji) i "IT Audit-a" (RiskAudit prema obnovljenoj definiciji). To je i česta tema specijaliziranih foruma koji okupljaju stručnjake za informacijsku sigurnost i reviziju. Pobornik sam stava da se suštinski, a velikim dijelom i izvedbeno, radi o istim stvarima. I "assessment" i "audit" moraju biti provedeni jednako kompetentno, detaljno i točno. Oba se procesa mogu defnirati u kontinuitetu. Osnovna je razlika u tome što IT Audit mora biti formalno utemeljen i izveden u kontekstu interne ili eksterne revizije, sukladno tako postavljenim ciljevima. "Security Assessment" ima različit formalni okvir. Njegovi naručitelji će biti i informatički odjeli i odjeli za informacijsku sigurnost, a naglasak će biti ili na testiranju sigurnosnih mjera (na razini projekta, aplikacije, pojedinačnih komponenti sustava...), ili na operativnom praćenju kvalitete ukupnih sigurnosnih mjera. Vjerujem da ćemo uskoro biti svjedoci konvergencije ovih modela, a naša se usluga nastavlja razvijati u tom pravcu.

Societe Generale: 45 dana poslije

Kakva je veza između intervjua virtualnog premijera Jutarnjem listu i senzacionalnog gubitka u francuskoj banci Societe Generale? U oba je slučaja manipulacija elektroničkom poštom odigrala određenu ulogu. U slučaju Jutarnjeg lista, elektronička pošta bila je ključni element zapleta, dok je u slučaju francuske banke elektronička pošta bila jedan od elemenata koje je koristio Jerome Kerviel u prikrivanju svojih transakcija. Naime, negdje pred kraj cijele avanture, Kerviel se "pokrio" e-mailom navodno pristiglim iz Deutsche Bank, a koji je do daljnjega trebao potvrditi uspješnost Kervielovih transakcija. No, Societe Generale je ipak provjerio autentičnost maila i pokazalo se da Deutsche Bank nema pojma o ovim porukama. To je, ujedno, bio i detonator koji je pokrenuo cijeli slučaj. Ova epizoda potvrđuje jednostavnost krivotvorenja elektroničke pošte i poučava da je, ako se e-mail želi koristiti kao mehanizam u kritičnim poslovnim transakcijama, potrebno koristiti takve sustave koji jamče očuvanje autentičnosti poruke i onemogućuju naknadni opoziv transakscija.

Prije dva tjedna objavljen je preliminarni izvještaj o slučaju Societe Generale. Izvještaj je izradila neovisna komisija, a posebno upada u oči činjenica da je tijekom 2006. i 2007. bilo 75 upozorenja o djelovanju Kerviela upućenih od njegovih kolega i izvedenih iz analiza poslovnih rizika. Nadležne osobe nisu reagirale na pravi način. Ostaje pitanje jesu li propustile primjetiti značaj indikatora koji pojedinačno možda nisu bili preupadljivi, no sagledani u ukupnom kontekstu morali su zvoniti na uzbunu? Ili su nadležne osobe bile opijene tadašnjim uspjesima Kerviela te su bili spremne previdjeti indikatore? Upravo je ova druga teza i glavno uporište Kervielove obrane koji tvrdi da ga je management mogao spriječiti da je to htio.

Izvještaj je potvrdio da je manipulacija s korisničkim pravima i autentikacijom korisnika bilo glavno Kervielovo uporište među općim kontrolnim mjerama informacijskog sustava. Kerviel je imao ovlasti za rad na informacijskom sustavu koje su prekoračile ovlasti potrebne na njegovom radnom mjestu, koristio je ovlasti drugih osoba, pristupni sustav nije evidentirao informacije o ključnim događajima (ili takve informacije nisu bile provjeravane). Na koncu, krivotvorio je i sadržaj elektroničke pošte. Ovi nedostaci su kombinirani s manjkavostima aplikativnih kontrola i kumulativni efekt bio je razoran.

U kontekstu ovih stranica htio bih ukazati na tri ključne pouke koje svi moraju izvući iz slučaja Societe Generale.

Prvo, posvetite kontroli pristupnih prava puno više pažnje nego što vam se u određenom trenutku čini da je potrebno. Izbjegnite situaciju u kojoj će prevladati subjektivni osjećaj kako nema potrebe za jačim kontrolnim mjerama jer, eto, kod vas nije bilo do sada nikakvih slučajeva zloupotrebe. Ova pouka osobito vrijedi za članove uprave koji moraju dobro poznavati sve rizike i hrabro "sponzorirati" takve projekte. Rukovodstvo IT službe ili informacijske sigurnosti treba koristiti jezik i argumente koji razumije uprava, i prezentirati takve rizike na pravi način.

Drugo, obratite pažnju na sve indikatore koji govore o "insiderskim" napadima. Takvi indikatori nisu glasni poput onih koje izazivaju vanjski napadi, zahtjevaju puno više pažnje i bolju pripremu, a naročito poznavanje konteksta poslovnog procesa. "Insiderski" napadi se, uglavnom, ne otkrivaju iz poruka IDS sustava već strpljivom, ponekad dosadnom, analizom mnoštva rutinskih događaja.

Treće, kontinuirana revizija/provjera aplikativnih i općih kontrolnih mjera, a naročito onih koje su vezani za pristupni podsustav i procese upravljanja korisničkim pravima, mora postati prioritetna obveza. Dinamika takvih provjera prerasla je godišnji ritam revizije, te mora biti znatno češća.

Čiji je zadatak provjeravati sigurnosne mjere?

Svaki program upravljanja informacijskom sigurnošću biti će nekompletan (i nedjelotvoran) ako ne uključuje i redovitu provjeru ispravnosti i pridržavanja propisanih mjera. Redovita provjera (naziva se i "auditing", "assessment"...) jedna je od ključnih aktivnosti složenog procesa koji svim zaintereseranim stranama mora pružiti jamstvo o adekvatnosti i učinkovitosti sigurnosnih procesa. Nije jedini - postoje i druge aktivnosti kako kroz horizontalni tako i kroz vertikalni pogled - no svakako je najkompleksniji i s najintenzivnijim doticajima prema komplementarnim aktivnostima.

Provjera sigurnosnih mjera se kod nas najčešće percipira kroz dvije izvedbe.

Jedan oblik susrećemo preko revizija poslovnih sustava, čiji plan realizacije mora obuhvatiti i provjeru rada informacijskih sustava, te daje ocjenu o potencijalnim nedostacima koji mogu utjecati na izvedbu poslovnog sustava. Drugi oblik susrećemo preko tzv. penetracijskih testiranja. Ova izvedba obično nije formalno pozicionirana kao poslovna revizija, a svojim je obuhvatom usmjerena prije svega na tehnički aspekt nekog dijela informacijskog sustava.

I to je, manje-više sve. No, provjera sigurnosnih mjera mora biti definirana sveobuhvatnije. Područja primjene danas su raznolikija od revizijskih aktivnosti i testiranja novih aplikacija. Pojavom regulatornih propisa, definicijom sigurnosnih standarda ili barem isticanjem smjernica o sigurnosnim mjerama, odgovornošću uprava tvrtki za djelotvornost sigurnosnog sustava i nekim drugim pokretačkim momentima, sigurnosna provjera je aktivnost za koji uprave tvrtki moraju biti i te kako zainteresirani.

Provjera sigurnosnih mjera mora krenuti od dobre definicije samih sigurnosnih mjera. One moraju biti dobro strukturirane već u fazi njihovog donošenja, propisivanja i izvedbe, a nakon toga treba se osigurati mehanizam njihove kontinuirane provjere, usporedbe s očekivanim ili prihvatljivim rezultatima, te generirati smislene indikatore koji će ukazivati na odstupanja ili će omogućiti mjerenje učinkovitosti pridržavanja sigurnosnih mjera.

Provjera sigurnosnih mjera mora biti dio nadležnosti i odgovornosti poslovne cjeline koja upravlja informacijskom sigurnošću i pri tome je veoma važno očuvati neovisnost od dijela organizacie koji operativno provodi pojedine sigurnosne mjere (čitaj, dakle, od službe informatike). Nemojte zaboraviti da provjera sigurnosnih mjera mora imati doticaj s procesom provjere i otklanjanja računalnih ranjivosti ("Vulnerability Management"), s testiranjem aplikativnih sustava u razvojnom ciklusu, s internom revizijom, s "compliance" incijativama, s upravljanjem operativnim rizicima, s forenzičkim aktivnostima...

Stoga, provjera sigurnosnih mjera mora postati dobro definiran proces koji neće biti izoliran od drugih cjelina (a naročito ne od službe informatike). Potrebno je očuvati nevisnost, vjerodostojnost i preciznost provjera, obuhvatiti organizacijske, administrativne i tehničke sigurnosne mjere, a indikatori i izvještaji moraju biti dostupni svim poslovnim cjelinama koje, svaka na svoj način, doprinose ukupnom uspjehu programa informacijske sigurnosti.