U Delu 1 smo prošli kroz to kako prepoznati i sprečiti phishing napade. Ali dobra zaštita smanjuje šansu da se nešto desi — ne garantuje da se neće desiti. Tu dolazimo do razlike koju mnoge firme ne prave — razlike između backupa i disaster recovery plana.
Backup nije isto što i disaster recovery plan
U tekstu o 3-2-1 backup strategiji objasnili smo zašto vam trebaju tri kopije podataka, na dva različita medija, sa jednom kopijom van lokacije. To je odlična osnova — ali backup vam samo garantuje da podaci postoje negde. Ne garantuje:
- koliko brzo možete da ih vratite u funkciju
- ko tačno šta radi u prvih sat vremena posle napada
- da li backup uopšte radi (mnoge firme ovo otkriju tek kada im zatreba)
- da li je i sam backup zaražen, ako je napad otkriven prekasno
Disaster recovery plan (DR plan) je dokument i procedura koja odgovara na pitanje: "Šta tačno radimo, kojim redosledom, i ko je odgovoran, kada se sistem uruši ili bude kompromitovan?"
Šta disaster recovery plan treba da sadrži
Jasno definisane uloge. Ko donosi odluku da se sistem isključi? Ko kontaktira IT podršku? Ko obaveštava klijente ako je potrebno? Kada nastane haos, ne želite da se ovo prvi put dogovara u tom trenutku.
RTO i RPO — dva broja koja svaka firma treba da zna.
- RTO (Recovery Time Objective) — koliko vremena firma sme da bude van funkcije pre nego što šteta postane ozbiljna. Za neke firme je to 2 sata, za neke 2 dana.
- RPO (Recovery Point Objective) — koliko podataka firma sme da izgubi, mereno u vremenu. Ako pravite backup jednom dnevno u ponoć, a napad se desi u 16h, gubite ceo taj radni dan.
Ova dva broja direktno određuju koliko često treba da pravite backup i koliko brzo vaš IT provajder treba da bude u stanju da reaguje.
Korak-po-korak procedura izolacije. Prvi refleks kod sumnje na zarazu treba da bude fizičko ili mrežno izolovanje pogođenog uređaja — ne gašenje, ne panika, nego isključivanje sa mreže dok se ne proceni šteta.
Testiran plan vraćanja iz backupa. Backup koji nikad niste probali da vratite u praksi je pretpostavka, ne plan. Redovno testiranje (bar dva puta godišnje) pokazuje da li restore stvarno radi i koliko traje.
Komunikacioni plan. Ako su pogođeni podaci klijenata ili partnera, ko i kako ih obaveštava? Ovo je i zakonska obaveza u određenim slučajevima, ne samo dobra praksa.
Kontakt lista van sistema koji može biti pogođen. Zvuči trivijalno, ali brojevi telefona IT podrške, provajdera i ključnih ljudi ne smeju da budu sačuvani isključivo na sistemu koji možda upravo gasite.
Zašto je ovo posebno važno posle phishing napada
Za razliku od otkaza hardvera gde znate tačno šta se pokvarilo, phishing napad često ostavlja pitanje otvoreno: da li je napadač samo ukrao lozinku, ili je već negde u sistemu i čeka? Zato disaster recovery plan posle sumnje na phishing mora da uključi i:
- promenu svih lozinki koje je pogođeni nalog mogao da vidi ili koristi
- proveru da li je pokrenuto neovlašćeno prosleđivanje mejlova (česta taktika — napadač podesi da mu se tiho prosleđuju svi mejlovi žrtve)
- proveru istorije prijava na nalog (neobične lokacije, neobično vreme)
- procenu da li je potreban restore iz backupa ili je dovoljno zatvoriti pristup
Zaključak
Phishing zaštita i disaster recovery plan nisu dve odvojene teme — to su dve strane istog novčića. Dobra obuka i tehnička zaštita smanjuju šansu da se nešto desi. Dobar DR plan određuje koliko će vas to na kraju koštati kada se, uprkos svemu, ipak nešto desi.
Firme koje imaju samo jedno od ova dva su na pola puta. One koje imaju oboje znaju tačno šta rade u prvih pet minuta krize — umesto da to smišljaju u panici.
Ako niste sigurni da li vaša firma ima realan disaster recovery plan, ili ne znate kada je backup poslednji put stvarno testiran, to je dobro mesto da počnete proveru.