Ukratko: Ako napad pogađa više od jedne web-stranice, trebate pružatelja usluge Incident Response koji će incident strukturirano obraditi. Preuzimamo sliku stanja, zaustavljanje, čišćenje i siguran oporavak, s jasnim ulogama i cjelovitom dokumentacijom. Odluke ostaju Vama, a mi osiguravamo tehničku osnovu.
Što Incident Response znači kod napada na poslužitelje
Incident Response je uređena obrada sigurnosnog incidenta. Umjesto užurbanih pojedinačnih radnji, rad slijedi utvrđene faze: prepoznati i procijeniti, zaustaviti, ukloniti, ponovno uspostaviti, naknadno obraditi. Svaka se mjera bilježi s vremenom i obrazloženjem.
Upravo je kod web-poslužitelja to važno. Poslužitelj s PHP aplikacijama često sadrži pristupne podatke za baze podataka, pružatelje platnih usluga, poštanske poslužitelje i sučelja. Tko je tamo upao, može se kretati dalje. Stanje nakon PHP2Shella pokazuje koliko brzo takva situacija može nastati: neautentificirano izvršavanje koda, više od 22,6 milijuna izloženih instanci prema Unit 42 i nema objavljenih, potvrđenih indikatora kompromitacije (Indicators of Compromise).
Kada Vam treba pružatelj usluge Incident Response
- pogođeno je ili bi moglo biti pogođeno više poslužitelja ili aplikacija
- postoji sumnja da su odliveni osobni podaci ili podaci o plaćanju
- napadač je možda još aktivan, primjerice putem tekućih veza ili novih računa
- postoji ucjena ili javna najava napada
- osiguranje, tijela ili poslovni partneri očekuju dokumentiran tijek
Kod jedne zaražene web-stranice često je dovoljna hitna pomoć kod hakirane web-stranice. Prijelaz na potpunu obradu incidenta dogovaramo s Vama čim se pokaže veći opseg.
Kako PHP SOS konkretno pomaže?
- Trijaža i slika stanja: Razjašnjavamo što je uočeno, koji sustavi i podaci mogu biti pogođeni i tko se interno mora uključiti. Rezultat je prva, pisana slika stanja s otvorenim pitanjima.
- Osigurati tragove i zaustaviti: Zapisnici, datotečni sustavi i baze podataka osiguravaju se prije nego što intervenirimo. Zatim izoliramo pogođene sustave, blokiramo kompromitirane pristupe i prekidamo prepoznatljive veze napadača.
- Ukloniti: Zatvaramo ulaznu točku, primjerice zakrpom na ispravljene verzije PHP-a i ponovnim pokretanjem svih workera, uklanjamo stražnja vrata i mijenjamo tajne. Za detaljnu analizu po potrebi uključujemo specijalizirane partnere za IT forenziku.
- Ponovno uspostaviti: Sustavi se kontrolirano vraćaju u rad, po mogućnosti iz čistih izvora ili na iznova postavljenim poslužiteljima. Nakon toga ih pojačano nadziremo zbog ponovnih upadljivosti.
- Naknadno obraditi: Dobivate završno izvješće s vremenskom crtom, uzrocima, mjerama i preporukama. Zajedno bilježimo što bi sljedeći put trebalo ići brže.
Čuvajte zapisnike poslužitelja i ne mijenjajte sustave prije nego što se sve osigura. Kod PHP2Shella BSI preporučuje privremeno isključiti s mreže web-poslužitelje koji se ne mogu odmah zakrpati.
Uloge i komunikacija tijekom incidenta
Incident traži jasne nadležnosti. Pokazao se dobrim mali krug: osoba s ovlastima za odlučivanje, tehnička kontakt osoba s Vaše strane i mi kao tehničko vodstvo. Koordinacijski sastanci održavaju se u utvrđenim razmacima, a rezultati se bilježe pisano.
Paralelno teku zadaci koje ne preuzimamo, ali za koje isporučujemo činjenice: provjera obveze prijave prema GDPR-u u roku od 72 sata, obavještavanje osiguravatelja, moguća prijava i krizna komunikacija prema klijentima i partnerima.
Što trebamo od Vas i što dobivate
Trebamo administrativne pristupe pogođenim sustavima, pregled infrastrukture i davatelja usluga, osobu s ovlastima za odlučivanje i spremnost da se sustavi po potrebi privremeno isključe. Korisni su postojeći planovi za slučaj nužde, skice mreže i sigurnosne kopije s datumom.
Dobivate tekući protokol incidenta, redovite slike stanja razumljivim jezikom, završno izvješće za upravu, službenike za zaštitu podataka i osiguravatelja te prioritetan popis poboljšanja. Kako se bolje pripremiti za sljedeći incident, opisuje Izrada IT plana za slučaj nužde za web-poslužitelje.
Tipične pogreške u prvim satima
Mnogi incidenti postaju teži jer se u uzbuđenju dobronamjerni koraci provode krivim redoslijedom. Ove obrasce često vidimo:
- Odmah postaviti iznova: Poslužitelj se briše i instalira iznova prije nego što je osiguran. Poslije se više ne može razjasniti jesu li podaci odliveni.
- Mijenjati lozinke sa zaraženog sustava: Ako napadač još ima pristup, vidi i nove lozinke.
- Obrisati samo vidljivu datoteku: Web shell je nestao, druga stražnja vrata u cron poslu ostaju.
- Zakrpati bez ponovnog pokretanja: Nove PHP datoteke leže na disku, a stari workeri i dalje rade u memoriji.
- Nitko ne vodi zapisnik: Poslije nitko ne zna tko je kada što promijenio. To otežava razgovore s osiguravateljem i tijelima.
Usklađen tijek sprječava te pogreške bez odgađanja zaustavljanja napada.
Što ne obećavamo
Ne obećavamo da će svaki incident biti potpuno razjašnjen; bez tragova ostaju pitanja, a to tako i pišemo u izvješću. Ne pružamo pravno savjetovanje ni izjave o odgovornosti ili osiguravajućoj zaštiti. Naš je cilj jasan završetak: na incidentu radimo dok nije zaključen i dokumentiran.
Česta pitanja
Koja je razlika između Incident Responsea i IT forenzike?
Incident Response ima za cilj zaustaviti incident i sigurno ponovno uspostaviti rad. IT forenzika detaljno i s dokaznom vrijednošću razjašnjava što se dogodilo. U praksi se oboje isprepliće, forenzika često paralelno osigurava tragove.
Kada bih trebao uključiti pružatelja usluge Incident Response?
Čim postoji sumnja da je napadač imao pristup sustavima, a opseg ne možete pouzdano procijeniti. Što ranije počne osiguravanje tragova, to se više kasnije može dokazati.
Tko odlučuje tijekom incidenta?
Odluke donosite Vi, primjerice o isključivanjima, komunikaciji ili prijavama. Mi pripremamo tehničke temelje, pokazujemo opcije s njihovim posljedicama i provodimo odluke.
Moram li uključiti policiju?
Prijava je u mnogim slučajevima smislena i važna za neka osiguranja. Za to su nadležne središnje kontaktne točke za cyber kriminal pri policiji. Hoćete li i kada podnijeti prijavu, odlučujete sa svojim odvjetnikom.