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?
25.10.09
18.8.09
Slučajevi Heartland i Hannaford, nastavak
Slučajevi Heartaland i Hannaford o kojema sam pisao na ovim stranicama, dobili su sudski nastavak, Jučer je objavljena vijest o podizanju optužnice protiv američkog državljanina Alberta Gozalesa. Gonzalesa se ovom prilikom sumnjiči da je jedan od hackera koji je upao u poslovni sustav tvrtki Heratland i Hannaford (ali i nekih drugih). Kažem ovom prilikom zato jer Gonzales već čeka suđenje za druge nedavne slučajeve krađe podataka - TJX, OfficeMax, Barnes & Noble... Gonzalesa se, po zadnjoj optužnici, tereti za krađu podataka o ukupno 130 milijuna kreditnih i debitnih kartica. Osim Gonzalesa, optužene su i dvije nepoznate osobe, po svemu sudeći iz Rusije, no pitanje je jesu li oni i jedini izvršitelji.
Ima i drugih zanimljivih detalja o optuženima (npr. Gonzales je bio dugogodišnji pouzdanik američke tajne službe), no mi ćemo analizirati način na koji je izvršena krađa.
Gonzales i društvo su brižljivo birali žrtve, krenuli su od popisa Fortune 500 tvrtki. Žrtve su, potom, proučili izbliza - obišli su njihove dućane kako bi upoznali opremu za procesiranje transakcija, detaljno su proanalizirali sustave za procesiranje plaćanja Internetom. Nije nemoguću da su se koristili i drugim metodama (socijalni inžinjering) kako bi se domogli vrijednih informacija o žrtvama.
Gonzales je potom pisao maliciozne programe posebno dizajnirane za računala žrtava. Cilj ovih programa bio je omogućiti neometan pristup Gonzalesa i društva računalima žrtava. Ovo su bili tzv. backdoor programi. Kako su uspjeli ove programe instalirati na računala žrtava? To iz dostupne dokumentacije nije sasvim razjašnjeno, no postoji nekoliko metoda, od zloupotrebe nezaštićene wireless mreže (što se i dogodilo u TJX), zloupotrebom SQL Injection nedostataka ili navođenja zaposlenika tvrtke na izvođenje malicioznog koda koji bi bio smješten na pripremljenim serverima (ne treba zanemariti ni tehnike socijalnog inžinjeringa). Vrlo je moguće da su napadači kombinirali različite tehnike, prilagođavali su okolnostima i profilu žrtvi. U svakom slučaju, puno je teži zadatak bio spriječiti otkrivanje malicoznih programa kada jednom budu smješteni na interni dio mreže. Za to se pobrinuo Gonzales: brižljivo je dizajnirao i testirao maliciozne programe, tako da ih nije bilo moguće otkriti sa 20 različitih antivirusnih programa (zasigurno se radi o svim najznačajnijim antivirusnim programima dostupnim na tržištu). U tom trenutku su napadači stekli prilično komfornu poziciju: mogli su neometano pristupati internoj mreži i pregledavati sve interesantne točke. Naravno, to je bila odskočnica za pristup do samih podataka koje su po istom kanalu slali nazad na vlastite servere. Način pristupa do podataka razlikovao se od slučaja do slučaja: kod jedne od žrtvi su naprosto snifali promet na mreži i otkrivali nekriptirane brojeve kartica, kod drugih su pristupali bazi podataka (po svemu sudeću SQL Injection napadima koji mogu biti i veoma sofisticirani)...
Sve što se desilo nakon toga, saznati ćete iz medija.
Iz ovih slučajeva mogu se naučiti mnoge stvari, npr:
Ima i drugih zanimljivih detalja o optuženima (npr. Gonzales je bio dugogodišnji pouzdanik američke tajne službe), no mi ćemo analizirati način na koji je izvršena krađa.
Gonzales i društvo su brižljivo birali žrtve, krenuli su od popisa Fortune 500 tvrtki. Žrtve su, potom, proučili izbliza - obišli su njihove dućane kako bi upoznali opremu za procesiranje transakcija, detaljno su proanalizirali sustave za procesiranje plaćanja Internetom. Nije nemoguću da su se koristili i drugim metodama (socijalni inžinjering) kako bi se domogli vrijednih informacija o žrtvama.
Gonzales je potom pisao maliciozne programe posebno dizajnirane za računala žrtava. Cilj ovih programa bio je omogućiti neometan pristup Gonzalesa i društva računalima žrtava. Ovo su bili tzv. backdoor programi. Kako su uspjeli ove programe instalirati na računala žrtava? To iz dostupne dokumentacije nije sasvim razjašnjeno, no postoji nekoliko metoda, od zloupotrebe nezaštićene wireless mreže (što se i dogodilo u TJX), zloupotrebom SQL Injection nedostataka ili navođenja zaposlenika tvrtke na izvođenje malicioznog koda koji bi bio smješten na pripremljenim serverima (ne treba zanemariti ni tehnike socijalnog inžinjeringa). Vrlo je moguće da su napadači kombinirali različite tehnike, prilagođavali su okolnostima i profilu žrtvi. U svakom slučaju, puno je teži zadatak bio spriječiti otkrivanje malicoznih programa kada jednom budu smješteni na interni dio mreže. Za to se pobrinuo Gonzales: brižljivo je dizajnirao i testirao maliciozne programe, tako da ih nije bilo moguće otkriti sa 20 različitih antivirusnih programa (zasigurno se radi o svim najznačajnijim antivirusnim programima dostupnim na tržištu). U tom trenutku su napadači stekli prilično komfornu poziciju: mogli su neometano pristupati internoj mreži i pregledavati sve interesantne točke. Naravno, to je bila odskočnica za pristup do samih podataka koje su po istom kanalu slali nazad na vlastite servere. Način pristupa do podataka razlikovao se od slučaja do slučaja: kod jedne od žrtvi su naprosto snifali promet na mreži i otkrivali nekriptirane brojeve kartica, kod drugih su pristupali bazi podataka (po svemu sudeću SQL Injection napadima koji mogu biti i veoma sofisticirani)...
Sve što se desilo nakon toga, saznati ćete iz medija.
Iz ovih slučajeva mogu se naučiti mnoge stvari, npr:
- Zaštitne mjere koje se baziraju samo na firewallu i antivirusnim programima su nedovoljne. Pisao sam već o tome kako antivirusni programi ne jamče otkrivanje svih malicioznih programa (u međuvremenu su se pojavili i drugi izvještaji koji potvrđuju ovo mišljenje).
- Kada se jednom vanjski napadač smjesti na internoj mreži, njegova aktivnost može biti gotovo nezamjetna, a za samog napadača izuzetno sadržajna i plodonosna. Uzorak ponašanja vanjskih napadača se približio uzorku ponašanja internih napadača.
- Interne ranjivosti postaju jednako kritične kao ranjivosti perimetarskih servera. Administratori sustava ne bi smjeli imati puno kredita za površnu konfiguraciju ili zakašnjelo patchiranje internih sustava.
- Ranjivosti radnih stanica se često smatraju manje prioritetnima od ranjivosti servera. To definitivno više nije tako. Upravo radne stanice mogu biti najbolja poluga vanjskim napadačima.
- Stalni nadzor događanja i prometa na mreži postaje neophodan. Takav nadzor pruža dodatno jamstvo u situaciji kada se više ne može bezgranično vjerovati firewall-ima i antivirusnoj zaštiti.
12.7.09
URIS - aplikacija za upravljanje IT rizicima
Na početku, dugujem ispriku zbog duljeg izbivanja s ovih stranica. Redovite poslovne aktivnosti i projekti su glavni razlozi izostanka. Glavninu vremena u svibnju i lipnju usmjerio sam na završetak rada na prvoj verziji aplikacije za upravljanje informacijskim rizicima. Aplikacija je razvijena u suradnji s kolegom Joškom Martincem iz tvrtke Adservio. Joško je napravio kompletan programerski posao (izvrsno, dodajem), a ja sam preuzeo brigu oko primjene korištene metodologije i prilagođavanja aplikacije procesu upravljanja informacijskim rizicima. Aplikaciju smo nazvali URIS. Važno je odmah naglasiti da aplikacija koristi javno dostupnu metodologiju upravljanja rizicima MEHARI. MEHARI postoji preko desetak godina, razvijena je u okviru francuske stručne udruge CLUSIF, te je obnovljena 2007. Dokumentacija o samoj metodologiji je dostupna na adresi https://www.clusif.asso.fr/en/production/mehari/mehari.asp. Osobito je zanimljivo da je metodologija objavljena pod GPL licencom. MEHARI je jako dobro opisan u raspoloživoj dokumentaciji (tekstovi i Excel tabele), no svaka ozbiljna primjena iziskuje aplikativnu nadogradnju.
Zbog čega uopće aplikacija za upravljanje IT rizicima? Jedan razlog svakako leži u činjenici da je imalo složeniju metodologiju nemoguće efikasno provesti kroz Excel tablice, a što se pogrešno smatra sasvim zadovoljavajućim tehničkim okvirom za vođenje projekata upravljanja IT rizicima. Drugi, važniji, razlog vezan je na ovaj prvi: iz prakse sam primjetio da korištenje nedovoljno robustnih metodologija neizbježno vodi u trivijalizaciju procesa upravljanja rizicima, što rezultira gubljenjen strateškog značaja kojeg bi upravljanje IT rizicima moralo imati. Korištenje kompleksnih metodologija (MEHARI je, svakako, veoma kompleksna i kompletna metodologija) vodi i boljem prihvaćanju od strane managementa i prisiljava sudionike na savjestan pristup projektu.
MEHARI je baziran na kvalitativnom pristupu koji, zahvaljujući složenom postupku donošenja ocjena, evoluira u polu-kvantitativni (pseudo-kvantitativni?) pristup, čime metodologija svakako dobiva na značaju. Osobito važnim smatram činjenicu da naša aplikacija koristi javno dostupnu i prihvaćenu metodologiju (iako sam bio na preko pola puta u razvoju vlastite metodologije).
Posao na aplikaciji obuhvaćao je, osim automatizacije postupka, nekoliko dodatnih komponenti. Tako je prijevod izvornog teksta svakako pomogao na uvođenju taksonomije pojmova za upravljanje informacijskim rizicima, još uvijek neujednačene u našem okruženju. Nadalje, aplikacija sadrži i različite izvještajne komponente, mogućnost upravljanja postupcima upravljanja rizicima u kontinuiranom razdoblju, kategorizaciju mjera i događaja prema COBIT-u i Basel II specifikacijama... Različiti noviteti su planirani i za slijedeće verzije.
Kome je namjenjena aplikacija? Osobit interes pokazuju svi oni koji iz različitih razloga moraju ispuniti regulatorne zahtjeve u pogledu upravljnaja IT rizicima, a to su prije svega banke (prema Odluci i Smjernicama HNB-a). Iako su mnoge banke postavile temelje procesa upravljanja rizicima, ovakva aplikacija i, prije svega, korištena metodologija omogućuju jednostavniju provedbu procesa upravljanja rizicima. Pored toga, neovisna i međunarodno raširena metodologija pruža dodatno jamstvo o zrelosti postupka upravljanja rizicima.
Neki od čitatelja ovih stranica su već upoznati s ovom aplikacijom, a svima zainteresiranima ću rado pružiti informacije o aplikaciji i korištenoj metodologiji.
Zbog čega uopće aplikacija za upravljanje IT rizicima? Jedan razlog svakako leži u činjenici da je imalo složeniju metodologiju nemoguće efikasno provesti kroz Excel tablice, a što se pogrešno smatra sasvim zadovoljavajućim tehničkim okvirom za vođenje projekata upravljanja IT rizicima. Drugi, važniji, razlog vezan je na ovaj prvi: iz prakse sam primjetio da korištenje nedovoljno robustnih metodologija neizbježno vodi u trivijalizaciju procesa upravljanja rizicima, što rezultira gubljenjen strateškog značaja kojeg bi upravljanje IT rizicima moralo imati. Korištenje kompleksnih metodologija (MEHARI je, svakako, veoma kompleksna i kompletna metodologija) vodi i boljem prihvaćanju od strane managementa i prisiljava sudionike na savjestan pristup projektu.
MEHARI je baziran na kvalitativnom pristupu koji, zahvaljujući složenom postupku donošenja ocjena, evoluira u polu-kvantitativni (pseudo-kvantitativni?) pristup, čime metodologija svakako dobiva na značaju. Osobito važnim smatram činjenicu da naša aplikacija koristi javno dostupnu i prihvaćenu metodologiju (iako sam bio na preko pola puta u razvoju vlastite metodologije).
Posao na aplikaciji obuhvaćao je, osim automatizacije postupka, nekoliko dodatnih komponenti. Tako je prijevod izvornog teksta svakako pomogao na uvođenju taksonomije pojmova za upravljanje informacijskim rizicima, još uvijek neujednačene u našem okruženju. Nadalje, aplikacija sadrži i različite izvještajne komponente, mogućnost upravljanja postupcima upravljanja rizicima u kontinuiranom razdoblju, kategorizaciju mjera i događaja prema COBIT-u i Basel II specifikacijama... Različiti noviteti su planirani i za slijedeće verzije.
Kome je namjenjena aplikacija? Osobit interes pokazuju svi oni koji iz različitih razloga moraju ispuniti regulatorne zahtjeve u pogledu upravljnaja IT rizicima, a to su prije svega banke (prema Odluci i Smjernicama HNB-a). Iako su mnoge banke postavile temelje procesa upravljanja rizicima, ovakva aplikacija i, prije svega, korištena metodologija omogućuju jednostavniju provedbu procesa upravljanja rizicima. Pored toga, neovisna i međunarodno raširena metodologija pruža dodatno jamstvo o zrelosti postupka upravljanja rizicima.
Neki od čitatelja ovih stranica su već upoznati s ovom aplikacijom, a svima zainteresiranima ću rado pružiti informacije o aplikaciji i korištenoj metodologiji.
29.4.09
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.
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.
21.4.09
"Uknown Uknowns"
Prošli sam tjedan pisao o izvještaju tvrtke Verizon. Jedan od najzanimljivijih odlomaka tog izvještaja nosi naslov "Uknown Uknowns". O čemu se radi?
Istražitelji računalnih incidenata su još prije nekoliko godina uočili zajednički uzorak u mnogim slučajevima: incidenti su omogućeni ili barem olakšani prisutnošću nekih resursa informacijske infrastrukture koji su u pravilu trebali biti poznati odgovornim osobama, ali koji za koje nitko nije znao. Tako su na mreži postojala računala za koje nitko nije znalo, osjetljivi podaci su se nalazili neočekivanim lokacijama, resursi su komunicirali neuobičajenim mrežnim konekcijama ili servisima, a nepoznati korisnički računi su bili redovita pojava. Ove su činjenice opisane kao "Uknown Uknowns", a uzrokovane su kako slučajnošći i nesmotrenošću tako i tendencioznim i zlonamjernim djelovanjem. Zajedničko im je da svojim prisustvom u velikoj mjeri olakšavaju sigurnosne prijetnje.
Možda uzorak iz Verizonovog istraživanja i nije do kraja reprezentativan da bi se izvukli definitivni zaključci, no i u ovom slučaju opžemo govoriti o dobroj ilustraciji prakse koja je sasvim sigurno stvarnost u mnogim okolinama. Uostalom, na brojnim sam se primjerima i sam osvjedočio u točnost ovih tvrdnji.
Kako se obraniti od nepoznatog?
Napore treba usmjeriti u dva pravca. S jedne strane, potrebno je redovito provjeravati podudaraju li se konfiguracijske postavke kritičnih informacijskih resursa s propisanim standardnim specifikacijama. S druge strane, potrebno je kontinuirano pratiti sve događaje i na vrijeme reagirati na neovlaštene promjene u konfiguraciji sustava.
Ovo je puno lakše napisati nego provesti. Provjera konfiguracijskih parametara podrazumijeva, na primjer kod Windows Server platforme, kontrolu nekoliko stotina konfiguracijskih parametara, pr čemu se ovi parametri prilično razlikuju po raznovrsnosti i kompleksnosti. Nadalje, praćenje događaja zahtjeva značajne resurse i koncetraciju stručnosti. Naravno, ni jedan od ovih zahtjeva ne može se uspješno provoditi bez specijaliziranih alata.
Svijest o informacijskoj sigurnosti doživjela je značajne poticaje u našem su okruženju tijekom nekoliko posljednih godina. No, sada nam predstoji slijedeća stepenica: iz dokumenata, pravilnika i certifikata potrebno je evoluirati u dobro upravljiv sustav čija će se sigurnosna uspješnost moći točno izmjeriti u svakom trenutku, a odstupanja prepoznati u realnom vremenu.
Do onda, biti ćete u prilici upoznati "Uknown Uknowns".
Istražitelji računalnih incidenata su još prije nekoliko godina uočili zajednički uzorak u mnogim slučajevima: incidenti su omogućeni ili barem olakšani prisutnošću nekih resursa informacijske infrastrukture koji su u pravilu trebali biti poznati odgovornim osobama, ali koji za koje nitko nije znao. Tako su na mreži postojala računala za koje nitko nije znalo, osjetljivi podaci su se nalazili neočekivanim lokacijama, resursi su komunicirali neuobičajenim mrežnim konekcijama ili servisima, a nepoznati korisnički računi su bili redovita pojava. Ove su činjenice opisane kao "Uknown Uknowns", a uzrokovane su kako slučajnošći i nesmotrenošću tako i tendencioznim i zlonamjernim djelovanjem. Zajedničko im je da svojim prisustvom u velikoj mjeri olakšavaju sigurnosne prijetnje.
Možda uzorak iz Verizonovog istraživanja i nije do kraja reprezentativan da bi se izvukli definitivni zaključci, no i u ovom slučaju opžemo govoriti o dobroj ilustraciji prakse koja je sasvim sigurno stvarnost u mnogim okolinama. Uostalom, na brojnim sam se primjerima i sam osvjedočio u točnost ovih tvrdnji.
Kako se obraniti od nepoznatog?
Napore treba usmjeriti u dva pravca. S jedne strane, potrebno je redovito provjeravati podudaraju li se konfiguracijske postavke kritičnih informacijskih resursa s propisanim standardnim specifikacijama. S druge strane, potrebno je kontinuirano pratiti sve događaje i na vrijeme reagirati na neovlaštene promjene u konfiguraciji sustava.
Ovo je puno lakše napisati nego provesti. Provjera konfiguracijskih parametara podrazumijeva, na primjer kod Windows Server platforme, kontrolu nekoliko stotina konfiguracijskih parametara, pr čemu se ovi parametri prilično razlikuju po raznovrsnosti i kompleksnosti. Nadalje, praćenje događaja zahtjeva značajne resurse i koncetraciju stručnosti. Naravno, ni jedan od ovih zahtjeva ne može se uspješno provoditi bez specijaliziranih alata.
Svijest o informacijskoj sigurnosti doživjela je značajne poticaje u našem su okruženju tijekom nekoliko posljednih godina. No, sada nam predstoji slijedeća stepenica: iz dokumenata, pravilnika i certifikata potrebno je evoluirati u dobro upravljiv sustav čija će se sigurnosna uspješnost moći točno izmjeriti u svakom trenutku, a odstupanja prepoznati u realnom vremenu.
Do onda, biti ćete u prilici upoznati "Uknown Uknowns".
Pretplati se na:
Postovi (Atom)