Krajem marta mjeseca sam imao priliku biti jedan od panelista ispred kompanije Ministry of Programming, prve panel diskusije “Upravljanje privatnim i poslovnim podacima: od Cloud-a do GDPR-a” na Adria Security Summit-u, koji predstavlja jednu od najprestižnijih konferencija iz oblasti informacione bezbjednosti u regionu i šire.
Zajedno sa panelistima Markom Gulanom (Scheneider Electric) i Ivanom Radošem (Malwarebytes) diskutovali smo o različitim temama, a jedna vrlo interesantna (koju sam izdvojio za ovaj blog) jeste šta to sve cloud nudi kao podršku u odgovoru na sajber incidente.
Izdvojene mjere za odgovor na sajber incident
Iako cloud provajderi kroz svoje servise nude mnogo toga u pogledu sajber incidenta, ovdje ću navesti tri mjere koje su primjer dobre prakse koje treba implementirati svaki tim a koje nam cloud provajderi svojim servisima upravo omogućavaju:
1. Namjenski privilegovan pristup cloud okruženju tokom sajber incidenta
Tokom sajber incidenta potrebno je da timu za odgovor na incidente omogućimo privilegovan pristup, odnosno admin pristup kompletnom okruženju u cloud-u. Prijedlog za to je da se kreira zaseban nalog sa administratorskim privilegijama, koji će koristiti tim za odgovor tokom sajber incidenta, budući da zlonamjerni hakeri mogu doći do pristupa cloud okruženju putem drugih naloga (npr. krađom kredencijala).
Isti treba biti kreiran i zaštićen u skladu sa najboljim praksama, što je svakako nužno da bude primjenjeno minimalno za druge admin naloge:
- Nalog treba da ima kompleksnu lozinku
- minimalno 16 karaktera
- Velika i mala slova
- Brojevi
- Specijalni karakteri
- Podešena multifaktorska autentifikacija
- Odobriti isključivo pristup samo sa whitelisted IP adresa
- Obezbjediti namjenski računar koji će se koristiti samo u slučaju sajber incidenta a na kom će se nalaziti privatni ključ (pem) za SSH pristup ovog namjenskog naloga naloga
2. Backup
Jedna od najvažnijih kontinuiranih aktivnosti koje organizacije trebaju da uspostave kao prevenciju od gubitka podataka, posebno tokom sajber incidenta, jeste kontinuiran backup. Pored zaštite od gubitka podataka koji je bitan sa stanovišta nastavka poslovanja, isto tako je bitno imati backup i sa stanovišta forenzike, odnosno kako bi se utvrdilo šta se desilo i otkrio počinilac. Kao jedna od najboljih praksi jeste da se kompletan backup radi na drugom nalogu, odnosno potpuno izoliranom nalogu od produkcijskog naloga.
Organizacije se često pitaju šta treba backup-ovati, a moj odgovor je sve što mogu:
- Logovi (zapisi)
- Baze podataka
- Snapshot-ovi instanci (virtuelnih mašina)
- Fajlovi koji se nalaze tj. skladište na namjenskim servisima za skladištenje
Iako u ovom blogu govorim samo o cloud okruženju, napomenuću da backup obrnuta metoda je takođe vrlo korisna, odnosno ukoliko ste u cloud okruženju sve to možete backup-ovati lokalno, i obrnuto ako vam je sve lokalno skladištite to u cloud-u, naravno ukoliko imate mogućnosti i finansija.
3. Proces izolacije
Kao jedna od aktivnosti odgovora na incident je svakako izolacija resursa koji su zaraženi odnosno hakovani. Ovaj proces uopšte nije jednostavan i zavisi od mnoštva parametara, te nije adekvatno postaviti neke univerzalne principe. S tim u vezi prijedlog je da organizacija uspostavi proces izolacije za svaki proces, na primjer za sve aplikativne mikroservise, na način ili da njegovim onemogućavanjem ostatak aplikacije nastavi sa normalnim radom ili pak da se obezbjedi redutantnost, odnosno da dati mikroservis bude zamijenjen drugim istim mikroservisom koji je pokrenuti odvojeno od prvog zaraženog.
Testiranje mora biti kontinuirano
Nakon što organizacije uspostave gore pomenute mehanizme tj. mjere, iste treba testirati kroz simulaciju sajber incidenta kako bi se što vjerodostojnije testirali uspostavljeni mehanizmi a zatim i otklonili određeni nedostaci. Simulacija incidenta, odnosno testiranje mjera ne treba da bude organizovana samo kada se mjere uspostave, nego redovno u određenim vremenskim intervalima koji ne moraju biti isti za sve mjere.
Nekoliko preporuka:
#01 Preporuka
Preporuka je da testiranje pristupa sa privilegovanim nalogom ili nalozima bude organizovano jednom kvartalno;
#02 Preporuka
Preporuka je da testiranje backup logova treba da se izvodi jednom mjesečno
#03 Preporuka
Preporuka da testiranje buckup baza treba da bude rađeno jednom kvartalno ili ranije ukoliko je urađen update baze podataka, izvršena izmjena na serveru ili servisu koji hostuje bazu podataka i slično
#04 Preporuka
Preporuka da testiranje backup datoteka treba da se izvodi jednom kvartalno ili ranije ukoliko je urađena neka izmjena na servisu za skladištenje
#05 Preporuka
Preporuka za testiranje izolacije je prilikom bilo koje izmjene servera, mašine ili pak prilikom novog release-a aplikacije – mikroservisa.
Model podijeljene odgovornosti
AWS primjer:
Za kraj ovog blog-a bih spomenuo Model podijeljene odgovornosti koji predstavlja zlatni standard kada je u pitanju informaciona bezbjednost. Koliko zapravo smatram važnim ovaj model govori i činjenica da je upravo to moje prvo pitanje – zahtjev, kada me pozovu da se uključim u odgovor ili pak u digitalnu forenziku nekog sajber incidenta. Jer upravo iz uvida u ovaj model, ukoliko to organizacija ima, zapravo dobijam informacije gdje i od koga mogu dobiti relevantne podatke za slučaj ili pak kako je najbolje da organizujem tim za odgovor shodno njihovim odgovnostima, a svakako i relevantnom znanju koje imaju.
Microsoft Azure primjer:
Prije nego odgovorim na pitanje, šta to cloud nudi kao odgovor na sajber incidente, prvenstveno bih napomenuo da prema modelu podjeljene odgovornosti kod tri najveća cloud provajdera (AWS, Azure i GCP) upravljanje podacima je odgovornost korisnika. Dakle, ako govorimo o podršci u incidentima u kojima su zahvaćeni podaci, provajderi u oblaku ne mogu mnogo da urade kako bi zaštitili naše podatke ukoliko mi sami to nismo uradili.
Cijelu panel diskusiju možete pogledati na sledećem video snimku: