Jesu li poslužitelji u oblaku sigurni?

Troškovi i vrijeme oporavka od sigurnosnog incidenta viši su nego ikada

IBM sigurnost i Institut Ponemon svake godine provode opsežna istraživanja slučajeva sigurnosnih incidenata te između ostalog izračunavaju prosječan trošak i vrijeme oporavka od sigurnosnog incidenta – curenja podataka. Osim što je 2022. prosječan trošak opravka narastao na 4,35 milijuna američkih dolara, što je najviši iznos u posljednjih 7 godina, interesantno je za primijetiti da je 4 od 10 najčešćih inicijalnih načina (vektora) napada usmjereno na krađu korisničkih vjerodajnica (korisničkog imena i lozinke). Istovremeno šokira informacija da je prosječno vrijeme za detekciju incidenta čak 243 dana, a vrijeme nužno da se izolira napad i uspostave normalne operacije čak 84 dana.

Kada postajemo meta napadača?

Kad odgovaramo na ovo pitanje važno je samo razumjeti motiv zbog kojeg netko želi doći do naših podataka. Postoji samo jedno pravilo, a to je mogućnost da napadač od preuzetih resursa ostvari direktnu financijsku korist. Najčešće u vijestima čitamo o napadima u kojima je nekoj kompaniji ukradena baza podataka ili je pristup njihovim podacima bio onemogućen korištenjem enkripcije (ransomware-a) i tražena otkupnina, no to više nije najčešći način na koji se napadači žele okoristiti.

Da se razumijemo, ransoware još nije potpuno iskorijenjen, to govori i nedavna epidemija ESXiArgs ransomware-a koji se 3. veljače 2023. godine počeo širiti neimuniziranim poslužiteljima na VMware ESXi tehnologiji, te izvještaji o novim ransomware-as-a-service uslugama na darknetu. Ipak, pojava novih sigurnosnih rješenja, cloud usluga sa zaštitom od ransomare-a i servisa poput No More Ransom www.nomoreransom.org ne samo da se smanjuju postotak uspješnosti ransomware napada, nego je postalo i sve manje vjerojatno da će se napadač okoristiti od uspješno provedenog napada.

Napadači zato danas traže nove načine ili već znaju kako drugačije iskoristiti i kapitalizirati vaše podatke i resurse poslužitelja nad kojim su preuzeli kontrolu. Tragično je to, što će napadač zbog direktne zarade od samo nekoliko stotina ili tisuća eura, kompromitirati vašu nematerijalnu imovinu vrijednu milione i prouzročiti štetu u vidu troškova oporavka, gubitka prihoda, stotina radnih sati, gubitka povjerenja kod korisnika, raznih odšteta, pa i regulatorno propisanih kazni, koje se mogu pojaviti i nekoliko godina nakon provedenog napada.

Povećanom popularnosti poslužitelja u oblaku i masovnim korištenjem društvenih mreža, napadačima je sve jednostavnije kompromitirati vaše sustave i ukrasti podatke. Zašto je to tako?
U vrijeme prije poslužitelja u oblaku trebali ste imati vlastiti poslužitelje, najčešće potpuno izolirane od interneta, odnosno ograničene samo na vaše djelatnike i korisnike. Uz poslužitelje je nužno išao i stručni kadar, stručnjaci za sustave, mreže i informacijsku sigurnost.

Provala u takav sustav je samo zbog jedinstvenosti rješenja bila je iznimno komplicirana, a odgovor na pokušaj provale uz stručan kadar je brz i efikasan. Prelaskom na upravljane poslužitelje u oblaku, osim eliminacije inicijalne investicije u sustav, smanjuju se i troškovi djelatnika, jer sad imate pružatelja usluge koji se brine o svemu (ili vam je barem usluga kod ugovaranja upravo tako predstavljena.) To nažalost u konačnici znači da korištenjem poslužitelja u oblaku zaista ne upravljate svojom nematerijalnom imovinom, jer se vaši podaci fizički nalaze kod nekog drugog. Nerijetko na drugom kraju svijeta.

Unificiran način implementacije usluge poslužitelja u oblaku, korporativnog ekosustava e-pošte i spremišta za dokumente, napadačima daje i unificirane metode napada koje su repetitivno primjenjive na sve ili gotovo sve korisnike takvih sustava, a ono što stoji između napadača i vaših vrijednih podataka je najčešće samo obična jednostavna lozinka.

Društvene mreže i razne aplikacije za razmjenu poruka, dodatno olakšavaju napadačima da dođu do korisnih informacija koje će im poslužiti u provedbi napada, a mogućnosti lažnog predstavljanja i socijalnog inženjeringa su im pojednostavljeni do te mjere da za njih ne moraju potrošiti ni jedan cent.

Zašto prosječno vrijeme za detekciju napada i izoliranje napadača (štete) traje stotine dana?

Pišući ovaj tekst želio sam detaljno opisati jedan scenarij uspješnog napada i noćnu moru oporavka i vraćanja kontrole nad sustavom, međutim to ne bih mogao napraviti bez da odam korištene hakerske metode, koje bi neki mogli pretvoriti u „kuharicu“ za jednostavnu provalu u sustav ili otkriti načine detekcije koje bi se tada mogle zaobići. Ostat ću samo na izjavi da provale u nedovoljno štićen, nesmotreno konfiguriran ili sigurnosno zapušten sustav mogu za napadača biti krajnje jednostavne.

Vratimo se odgovoru na pitanje. Vrijeme potrebno za detekciju. Nakon uspješnog ulaska u sustav, napadač će željeti svoje prisustvo što duže držati u tajnosti, odnosno barem toliko dok se ne uvjeri da može u potpunosti preuzeti kontrolu nad sustavom i izolirati vas (i vaše administratore), od mogućnosti da vrate kontrolu nad sustavom i da su sve vaše sigurnosne kopije one u kojima napadač već ima pristup. Nažalost, tada vrijeme detekcije najčešće koincidira s trenutkom kad napadač pokreće svoju „završnu igru“ u kojoj vas potpuno izolira od pristupa sustavu i/ili obavlja planiranu štetnu radnju.

Idemo sad pretpostaviti da se dogodilo upravo to. Imate uslugu kod nekog velikog globalnog pružatelja, napadač vam je preuzeo sustav na način da je došao do lozinke jednog od administratora, a vama oduzeo prava upravljanja njime. Kako sad vratiti kontrolu? Sami ne možete apsolutno ništa i jedini način da vratite uslugu je da se obratite direktno pružatelju usluge – globalnoj korporaciji koja primjerice ima milijune korisnika poput vas i tisuće prijava hakerskih napada (pravih i lažnih) dnevno.

Kako bi diferencirala prave od lažnih prijava i umanjila rizik ljudske greške, prva komunikacija iz te kompanije nakon prijave biti će od robota, a ne od fizičke osobe (Specijaliste za podršku.), također tu komunikaciju čete čekati nekoliko sati, iako bi robotu vjerojatno bilo dovoljno nekoliko sekundi da odgovori. (Ovo bespotrebno čekanje prvog odgovora nije primjer jednog globalnog pružatelja, slično radi više njih.) Najčešće će se u prvom odgovoru tražiti od vas da se dodatno identificirate, kako bi uopće počeli raditi u smjeru rješavanja vašeg problema. Sljedeće što će ta kompanija napraviti (nakon ozbiljne sumnje u hakerski napad), je u potpunosti blokirati vam uslugu, kako bi zaustavila daljnje štetne radnje od strane napadača. Ovo je potpuno razumna i sa sigurnosne strane ispravna odluka, no sada vaša usluga ne samo da nije pod vašom kontrolom, nego i ne radi. Nestala je s interneta.

Ako mislite da je ovo vrhunac vaših problema, varate se. Problemi tek počinju. Sada se počinju javljati vaši korisnici (interni ili eksterni) da usluga ne radi, u gorem slučaju javljat će se s prijavama da ste im u poruci poslali poveznicu na zloćudni software, phishing ili ponudu za kupnju nekog proizvoda ili usluge koja nema veze sa vama… Tada postaje jasno da su vam ukradeni i drugi korisnički kontaktni podaci, a vaš poslužitelj je postao platforma za distribuciju spam-a, phishing poruka ili malware-a. Takve aktivnosti vas stavljaju na razne crne liste, ruši vam se rating u reputacijskim centrima, a antivirusni i antimalware software-i vašu uslugu/domenu/stranicu/poruke/mailove počinju blokirati i blokirat će je neko duže vrijeme nakon što i vratite funkciju i kontrolu nad uslugom.

Što napraviti kod sumnje na hakerski napad?

Definitivno već kod sumnje na hakerski napad (nemogućnost pristupa, prestanak rada usluge, prijave o nekontroliranom širenju neželjenih komunikacija i sl.) odmah trebate kontaktirati svog DPO i stručnjaka za informacijsku sigurnost, preferabilno nekog sa iskustvom vraćanja kontrole nad eksternaliziranim sustavima i direktnim kontaktima s ključnim ljudima u organizaciji kod koje imate uslugu. Ove dvije osobe pokrit će izvjestan regulatorni problem sa curenjem korisničkih podataka (DPO) i izvršiti oporavak usluge prema unaprijed napravljenom ili ad-hoc planu oporavka. Također nije loše odmah razmišljati i o alternativnim rješenjima uspostave normalnih operacija, kako bi nastavili barem dio poslovanja sve dok ne vratite kontrolu nad primarnim sustavima.
Kvalitetan odziv na napad zaista znači sve u poboljšanju vremena oporavka.

Nespretni i neadekvatni koraci, nespretna ili neprimjerena komunikacija prema pružatelju cloud usluge, može dodatno usporiti, pa čak i u potpunosti onemogućiti oporavak usluge. Trebate znati, da pružatelji cloud usluga sve incidente na svojim poslužiteljima gledaju prije svega kao vlastiti problem i sigurno vam neće omogućiti ponovo korištenje usluge ako nisu 100% sigurni da je svaka prijetnja integritetu njihovih sustava i infrastrukture eliminirana, a to često zahtijeva angažman dodatne grupe stručnjaka i/ili stvara dodatne troškove kod pružatelja usluge.

Mogu li onda poslužitelji u oblaku uopće biti sigurni?

Apsolutna sigurnost je naravno nemoguća, ali solidna sigurnost s rizicima koje možete prihvatiti je svakako moguća. Radi jednostavnijeg korištenja, pružatelji cloud usluga za vas neće inicijalno „pritegnuti“ sigurnost na način kako bi to preporučili stručnjaci, pa nakon postavljanja usluge, nužno je aktivirati dodatne sigurnosne opcije ili dodati samostalna sigurnosna rješenja i tako očvrsnuti cijeli sustav. Dodatno, vaše intelektualno vlasništvo ne smije biti u rukama samo jednog pružatelja usluge. Ako ništa drugo, sigurnosno kopiranje cjelokupnog sadržaja ugovorite sa potpuno drugim pružateljem, idealno na lokaciji udaljenoj tisuće kilometara od primarnog podatkovnog centra. Ulaganje u napredne sustave informacijske sigurnosti također treba biti u skladu s vrijednosti čuvane imovine. Iako je većina naprednih sustava prije svega namijenjena prevenciji, a tek onda detekciji, ranije spomenuto istraživanje pokazuje da su u slučaju incidenta kod korisnika naprednih sustava, vremena i troškovi oporavka usluge nakon incidenta znatno manji.

Kada ugovarate uslugu o kojoj vam ovisi poslovanje, (poslovne aplikacije, korporativni mail, čuvanje poslovne dokumentacije i sl.) nužno je imati plan oporavka u slučaju incidenta i redovito ga testirati.
Pružatelj usluge bi, osim što odgovara vašim specifikacijama, certificiran je i osiguran, trebao biti i lokacijski pristupačan, te vam predočiti svoje planove oporavka i objasniti (dokumentirati) proces koji trebate proći u slučaju potrebe za oporavkom vaše usluge koje imate kod njih, kako bi taj proces ugradili u svoj službeni plan oporavka.

U reviziji sigurnosti među prvim pitanjima postavim ova:

„Imate li plan oporavka?“
– Daaa.
„Jeste li ga testirali?“
– Pa naravno!
„Kako ste ga testirali i koje vam je bilo vrijeme oporavka?“
-Uspješno smo vratili poslužitelj, konfiguraciju i podatke iz sigurnosne kopije, a vrijeme oporavka nam je bilo 15 minuta.
„15 minuta? Backup vam je dakle na istoj lokaciji, u istom data centru i kod istog pružatelja usluge?“
-Da.
„Jeste li testirali worst case scenarij?“
-Koji je worst case scenarij?
„Pa ne znam. Npr. Datacentar izgori u požaru.“
-Ma to se ne može dogoditi.
„Ne? Hoćete primjere? ????“

Worst case scenariji je izvjestan i kod hakerskim napadom kompromitiranog sustava u oblaku, jer je prva reakcija pružatelja usluge u potpunosti suspendirati i izolirati takav sustav, kako bi zaštitio svoju infrastrukturu i svoju reputaciju.

Dosta često je samo dokumentiran plan oporavka i odlično vrijeme oporavka u skladu s inputima vašeg pružatelja usluge dovoljno da oduševi vaše revizore, no u realnoj situaciji najčešće je totalno promašen i potpuno beskoristan. Imajte to u vidu.

Na početku teksta sam rekao da je često jedina barijera između vaših podataka i zlonamjernih trećih strana samo vaša lozinka. Jedan od najefikasnijih načina zaštite vašeg sustava su dobre lozinke, višestruke autentifikacije ili nužnost korištenja privatnih certifikata za pristup sustavu.

Redovni treninzi informacijske sigurnosti su također iznimno korisni, jer ne samo da će naučiti vaše zaposlenike kako odabrati dobre i sigurne lozinke, naučit će kako ih čuvati, te kako prepoznati phishing poruke i zaštititi lozinke od odavanja. Jer uvijek vrijedi pravilo: Vaš sustav je siguran koliko i njegova najslabija karika. Za korisne upute kako napraviti sigurne lozinke i sačuvati ih od odavanja pročitajte naš tekst na tu temu.

„Manji“ sigurnosni incidenti također mogu biti skupi

Pod „manjim“ sigurnosnim incidentima pretpostavljam one kod kojih nije došlo do curenja podataka, kompromitiranih podataka za prijavu ili gubitka kontrole nad sustavom.

Manji sigurnosni incidenti mogu biti i incidenti na infrastrukturi vašeg pružatelja usluge, koji će vam na neki način degradirati uslugu. Ovi incidenti mogu biti svakodnevni na sustavima u oblaku, jer osim vas iste sustave koriste i druge osobe, koje mogu imati zle namjere ili samo iskorištavati resurse sustava na način koji nije bio namijenjen kroz ugovorenu uslugu. U principu vrijedi pravilo, što je usluga jeftinija, to je veća mogućnost da ju osim vas koristi i zloćudna treća strana. Besplatni servisi su naročito ranjivi, jer napadači njihovim korištenjem ne moraju dati svoje platne podatke i tako otkriti svoj identitet ili stvoriti tragove koji bi doveli do otkrivanja njihovog identiteta.

U svojim popisima rizika kod korištenja dijeljenih poslužitelja u oblaku, slobodno stavite i „Treća potpuno nepovezana strana degradira uslugu našeg pružatelja.“. Kad procijenite vjerojatnost i kvantificirate moguću štetu, korištenje takve usluge je možda nešto što biste radije izbjegli.

Evo ovaj tjedan sam imao slučaj jedne tvrtke koja mi inače e-poštom šalje određene podatke. Ti podaci su mi uvijek bili korisni i pravovremeni, no u nekom trenutku su krenuli izostajati. Danima nisam primao njihove poruke e-pošte, a kad sam ih konačno slučajno pronašao u mapi neželjene pošte, ti podaci su već bili zastarjeli. Razlog zbog kojeg su poruke završavale u neželjenoj pošti je taj što im je poslužitelj za slanje e-pošte završio na nekoliko crnih lista, jer je netko tko koristi isti poslužitelj, krenuo slati zloćudne poruke e-pošte po svijetu. Radilo se o dijeljenom poslužitelju jednog od vodećih globalnih pružatelja usluge e-pošte u oblaku. Ne samo da me iznenadilo što se to uopće može dogoditi reputabilnom pružatelju usluge e-pošte za poslovne korisnike, šokiralo me i vrijeme koje im je bilo potrebno da izoliraju kompromitirani poslužitelj i ponovo uspostave normalno slanje e-pošte.

Možda većina nas ne smatra strašnim što nam je e-pošta tu neko vrijeme završavala u neželjenoj pošti primatelja, no takvi „manji“ incidenti također mogu dovesti do gubitka prihoda, povjerenja ili reputacije, ali zbog izostanka neke važne komunikacije mogu stvoriti i ozbiljne financijske štete.

Ostavi komentar