Revizija aplikacija

U redovnom poslu interne IT revizije, revizija aplikativnih rešenja je poslednja faza rada u pristupu od vrha ka dole (top down). Pri tome bi trebalo imati u vidu da je svaka aplikacija, shodno pahuljastoj teoriji, jedinstvena, bilo da podržava finansijske ili operativne funkcije poslovne organizacije, i stoga će imati svoj sopstveni jedinstveni skup zahtevanih kontrola. Nemoguće je dokumentovati specifične zahtevane kontrole koje bi bile primenljive na sve poslovne aplikacije. Međutim, ono što će se ukratko opisati niže u tekstu, su neke opšte kontrolne preporuke koje bi trebalo da budu primenjene i aplicirane u bilo kojoj aplikaciji bez obzira na njenu funkciju.

Tipično razmatranje u procesu interne IT revizije uključuje:

• Osnovne komponente revizije aplikacija,
• Kako korisno proširiti ili suziti obim procesa interne revizije aplikacija,
• Kako izvršiti detaljnu analizu (drill down ((drill down – u informacionim tehnologijama, drill down znači detaljnu analizu, odnosno da se premeštamo iz sumarnih informacija do detaljnih podataka, fokusirajući se na na nešto. U okruženju grafičkog korisničkog interfejsa (Graphical User Interface – GUI), “drill down ” može da se uključi klikom na neko predstavljanje u cilju da se otkrije više detalja o njemu. )) ) o mogućim ishodima sa okvirom i ključnim konceptom,
• Detaljni koraci za reviziju novih aplikacija.

Suština revizije aplikacija

Savršeno je kada interni IT revizor ima odličan revizorski program koji može da primeni na neku aplikaciju. Međutim, realnost je da su interni IT revizori najčešćei suočeni sa novim idejama i prilazima za rešavanje poslovnih problema sa novim tehnologijama koje zahtevaju savremenije, novije, revizorske programe. Ako se interni IT revizor ”bori” sa postavljenim pitanjima, on će po pravilu naći okvir i najbolju praksu u daljem izlaganju kao vid određene pomoći.

U tom prilazu interni IT revizor može da primeni neku od važećih metodologija za svoj rad kao što su: PPTM ((PPTM – People, Processes, Tools, Measures, Ljudi. Procesi, Merenja, Alati )), STRIDE ((STRIDE – Jednostavni model rizika pretnji. Kategorije pretnji su Spoofing of user identity, Tampering, Repudiation, Information disclosure (privacy breach), Denial of Service (D.o.S.), Elevation of privilege, Prevara identiteta, Smetnje kod podataka, Odricanje, Informaciono obelodanjivanje, Uskračivanje usluge, Dizanje privilegija  izvor Wikipedia.)), PDIO ((PDIO – Planning, Design, Implementation, Operations, Planiranje, Projektovanje – dizajn, Implementacije, Operativnost)).

Važno je prihvatiti da slojeviti pristup obezbeđuje više bezbednosti tokom dugog vremena nego jedna komplikovana bezbedonosna arhiktektura. Interni IT revizor može, na primer, da koristi listu kontrole pristupa ACL ((ACL – Access Control List )) na mrežnoj i firewall opremi samo da bi omogućio neophodni saobraćaj da dopre do aplikacije. Ovaj prilaz značajno smanjuje globalni rizik ugrožavanja sistema u kome se izvode aplikacije jer brzo eliminiše pristup uslugama, portovima i protokolima da bi na drugi način bili dostupni ugrožavanju.

U praksi postoji pozitivna (bela lista) bezbedonosnih modela koja omogućava izvršenje samo onih aktivnosti koje su na listi, isključujući unapred sve drugo. Međutim, negativna (crna lista) bezbedonosnih modela omogućava sve po definiciji, eliminušući samo stavke za koje interni IT revizor zna da su loše. To je izazov, na primer, za antivirus programe koje interni IT revizor, ili zaduženo lice mora konstantno da ažurira da bi išao u korak sa brojnim novim mogućim napadima (virusima), koji mogu da utiču na bezbedonosni sistem poslovne organizacije. Problem sa ovim modelom, ako je interni IT revizor prinuđen da ga koristi, je da zadužena lica moraju apsolutno da zadrže model ažurnim. Čak i sa ažuriranim modelom, može da postoji ranjivost a da pri tome interni IT revizor ne zna odakle dolazi napad  na poslovnu organizaciju, koji iznenada izbija na površinu, jer je sam model mnogo širi nego ako interni IT revizor koristi pozitivni bezbedonosni model.

Praktično postoje tri osnovna odgovora kada je aplikacija neuspešna. Interni IT revizor može da omogući, blokira, sprečava ili da prijavi grešku. Uopšte, aplikativne greške bi trebalo propustiti na isti način kao odbacivanje operacija koje su viđene od strane krajnjih korisnika. To je posebno važno jer tada krajnji korisnici nemaju pridodate informacije da to koriste tako da mogu da im pomognu da ugroze bezbednost sistema.

Nekorektna implementacija ili provera ulaznih kontrola konzistentno ostaju glavni razlog zašto aplikacije trpe ranjivost. Primeri uključuju ublažavanje odliva podataka i uvođenje mogućeh napada.

Pored revizije ulaznih kontrola potrebno je sprovesti kontrole interfejsa, kontrole obrade, pristupne kontrole, kontrolu izvršavanja prepisa i obnova (back-up i recovery), čuvanje podataka i njihova klasifikacija, uticaj operativnih sistema, baza podataka i druge infrastrukture na aplikativne kontrole. Inicijalno bi trebalo sprovesti kontrolnu listu provere “check-list“koja  ima 23 osnovne tačake za razmatranje kojima bi trebalo da se bavi interni IT revizor. Kao što je već ukazano, po potrebi,  kontrolna lista provere se može i treba da proširi sa dopunskim elementima.

Sa ovim se završava ova kratka sesija vezana za procese interne IT revizije, mada bi trebalo imati u vidu da je potrebno obuhvatiti i sledeće oblasti i postupke u kojima deluje interna IT revizija kao što su:

• Revizija kompanijskih projekata
• Okvir i standardi
• Forenzičko računovodstvo
• Forenzička IT revizija