Napadi na Google - očekivano iznenađenje

Ovotjedna objava napada kineskih hackera na Google i tridesetak drugih američkih kompanija izazvala je brojne i glasne reakcije, no vjerujem da stručnjaci za računalnu sigurnost nisu previše iznenađeni tehničkim aspektom ovog ofenzive (ja sam o tome pisao tijekom ljeta prošle godine). Tijekom 2009. mogla su se pročitati brojna upozorenja o transformaciji klasičnih računalnih prijetnji i tehnika napada koju ove prijetnje koriste, uz najave trenda koji se upravo manifestirao. Frontalni i pompozni napadi kojima je cilj stvaranje publiciteta su odavno zastarjeli. Nastupilo je razdoblje diskretnih i ciljanih napada, usmjerenih na poznatu žrtvu. Cilj napadače nije steći pet minuta slave što je brže moguće, već strpljivim djelovanjem doći do svojih ciljeva, ma kakvi oni bili - od podataka iz kartičnog poslovanja pa do povjerljivih poslovnih tajni. Slava, pri tome, uopće nije bitna.

Suština ove taktike je slijedeća: sofisticiranim tehnikama prodire se u mrežu žrtve, a odmah potom se korišteni alati odbacuju poput padobrana, te se napadač ukopova u dostupnu nišu, zadržavajući prikrivenu i stalnu vezu sa nalogodavcima. Napadač se u drugoj fazi može ponašati donekle ležernije i na raspolaganju mu je dovoljno vremena da otkrije i iskoristi brojne nedostatke unutarnje mreže. Postavljeni cilj je na dohvat ruke. Pored toga, treba znati da klasični obrambeni mehanizmi - firewall i antivirusna zaštita - nisu nimalo djelotvorni kod ovih napada.

Činjenica da je slučaj Google razvikan i razvučen po svim medijima ne poriče moju tezu da slava nije motiv ovih napada. Ovaj slučaj je razvikan prije svega zato što je Google to htio, iz vlastitih razloga kojima se bave vanjskopolitički novinari.

Vjerujem da ste već doznali da su napadači u slučaju Google zloupotrebili zero-day ranjivost u Internet Exploreru (a ne nedostatak Acrobat Reader-a, kako se u prvi mah pomislilo). Nije mi poznato zbog čega Google koristi IE pored vlastitog preglednika za kojeg tvrde de je sigurnosno besprijekoran. Objašnjenje da su kompromitirana računala služila testiranju nisu najuvjerljivija...

Kineski su napadači nekom od tehnika socijalnog inžinjeringa naveli žrtvu da posjeti web stranicu sa malicioznim kodom, odmah potom je računalo žrtve bilo zaraženo, a instalirani program je uspostavio siguran i kriptiran kanal, prema komandnom centru iz kojeg je primao naredbe. Nije poznato što je točno napadač radio nakon toga, tvrdnje o krađi podataka o mail računima kineskih disidenata treba tek potrditi.

Na tehničkoj razini nema iznenađenja, no na socijalnoj ili političkoj razini ovi će slučajevi uzrokovati nekoliko značajnih pomaka.

Ovaj napad dokazuje da su ciljani napadi postali realnost ne samo kod ekstremno atraktivnih i vrijednih ciljeva - npr. prema američkim vladnim institucijama - nego i u poslovnom svijetu. To, nažalost znači, da se tehnike napada približavaju komodizaciji, a samo je pitanje vremna kada će kompetencije armije kineskih hackera - možda bi "armija" trebalo pisati s velikim A, postati dostupna i običnim smrtncima - mislim na one sa crne strane.

Stoga bi svi praktičari upravljanja rizicima morali prilagoditi standardne procjene koje se odnose na visinu prijetnji malicioznog ljudskog faktora. Ove prijetnje postaju sve realnije, a motiviranost i znanje su svakako značajne kompetente prijetnji koje dolaze, ne samo iz okruženja kineske armije hackera, nego i iz iz drugih sličnih laboratorija.

Naravno, pretpostavljam da ste komponentu utjecaja računalnih ranjivosti već ranije povećali.

Na kraju, kako se obraniti od ovih prijetnji. Pored mjera koje sam naveo u tekstu o slučaju Heartland, mislim da će još jedna mjera naći svoje opravdanje (iako, priznajem, do sada nisam striktno inzistirao na ovoj mjeri). Naime, do sada se očekivalo da su isključivo perimetarske adrese izložene vanjskim napadačima, pa se testovima nastojalo simulirati maksimalnu kompetenciju i sposobnost ovih napadača. Interni testovi su bili rijetki i, rekao bih, površni (obično se računalo na relativnu dobronamjernost i umjerenu tehničku kompetenciju internih korisnika). Ovo će se definitivno morati promjeniti. Testiranje sigurnosti interne mreže morati će uzeti u obzir i negativni potencijal napadača ubačenih iz vanjskog okruženja.

"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".

Proces upravljanja računalnim ranjivostima

Svim korisnicima servisa QualysGuard (a i onima koji će to postati) preporučujem da pročitaju zanimljiv tekst na stranicama organizacije SANS. U tekstu se iznosi praktično iskustvo u izgradnji programa upravljanja ranjivostima, iz vizure korisnika servisa QualysGuard. Usput, svakako razgledajte Reading Room sekciju na stranicama organizacije SANS, ako do sada već niste to učinili. Na tom ćete mjestu naći niz zanimljivih tekstova o implementaciji mjera informacijske sigurnosti.

U čemu je razlika između procjene ranjivosti ("Vulnerability Assessment) i upravljanja ranjivostima ("Vulnerability Management")? Procjena ranjivosti je tehnička aktivnost koja se obično provodi ne prečesto, ponekad i neredovito. Obuhvaća provjeru prisutnosti eventualnih tehničkih nedostataka i ranjivosti na mrežnim resursima, a ponajprije se provodi na perimetarskom dijelu informacijskog sustava. Ako se provodi kako treba, procjena ranjivosti će u jednom trenutku dosegnuti kritičnu točku: broj resursa koje treba provjeriti naglo raste, učestalost provjere zauzima nerijetko i tjednu dinamiku, u provjeru se uključuju i druga mjesta u organizacijskoj hijerarhiji (ne samo mrežni tehničari već i voditelji sigurnosti, revizori, rukovoditelji, administratori nemrežnih sustava...), provjera se počinje provoditi i na internim resursima... Procjena ranjivosti kao tehnička aktivnost prelazi u proces i nastaje upravljanje ranjivostima. Izvještaji o utvrđenim ranjivostima prelaze u detaljan "workflow" koji uključuje i osobe nadležne za implementaciju popravaka, vlasnike resursa, a ponekad i revizore. Upravljanje ranjivostima reflektira se i na "compliance" proces (pogledajte i ovaj tekst).

Dokument na koji vas upućujem govori upravo o ovim elementima. Primjetiti ćete da postoje terminološke razlike između spomenutog dokumentu i ovog teksta, no suštinski pokriveni su svi bitni aspekti upravljanja ranjivostima.

Treba reći i da je tvrtka Qualys je pionir a danas i jedan od lidera poslovnog modela "Software-as-a-Service" (SaaS). Rekao bih da je upravo informacijska sigurnost idealan kandidat za primjenu ovog modela (naravno uz uvijet njegove dobre tehnička izvedbe). Naime, informacijska se sigurnost ne ubraja u "core" interese managementa i tvrtke za sada ulažu samo neophodne resurse. S druge strane, otkrivanje i upravljanje ranjivostima zahtjeva kontinuiranu predanost na različitim tehničkim i organizacijskim razinama, a dostignuća samog procesa nisu uvijek vidljiva. Dakle, mali je korak do zanemarivanja ovog procesa. Model izvedbe servisa QualysGuard u potpunosti rasterećuje organizaciju od rutinskih aktivnosti, jamči ažurnost i preciznost.

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.

Č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.