Stručně: Pokud útok zasahuje víc než jeden web, potřebujete dodavatele reakce na incidenty (incident response), který incident zpracuje strukturovaně. Převezmeme obraz situace, omezení škod, vyčištění a bezpečnou obnovu, s jasnými rolemi a nepřerušenou dokumentací. Rozhodnutí zůstávají na vás, technický základ zajistíme my.
Co reakce na incidenty při útocích na server znamená
Reakce na incidenty (incident response) je uspořádané zpracování bezpečnostního incidentu. Místo hektických jednotlivých akcí se práce řídí pevnými fázemi: rozpoznat a zařadit, omezit, odstranit, obnovit, vyhodnotit. Každé opatření se zaznamená s časem a odůvodněním.
Právě u webových serverů je to důležité. Server s aplikacemi PHP často obsahuje přístupové údaje k databázím, platebním službám, poštovním serverům a rozhraním. Kdo se tam dostal, může se pohybovat dál. Situace po PHP2Shell ukazuje, jak rychle taková situace může vzniknout: spuštění kódu bez ověření, více než 22,6 milionu exponovaných instancí podle Unit 42 a žádné zveřejněné potvrzené indikátory kompromitace (IOC).
Kdy potřebujete dodavatele reakce na incidenty
- je postiženo nebo by mohlo být postiženo více serverů či aplikací
- existuje podezření, že unikly osobní nebo platební údaje
- útočník je možná stále aktivní, například přes probíhající spojení nebo nové účty
- došlo k vydírání nebo k veřejnému oznámení útoku
- pojišťovna, úřady nebo obchodní partneři očekávají zdokumentovaný postup
U jednoho napadeného webu často stačí nouzová pomoc při napadeném webu. Přechod k plnému zpracování incidentu s vámi probereme, jakmile se začne rýsovat větší rozsah.
Jak konkrétně pomáhá PHP SOS?
- Triáž a obraz situace: Zjistíme, co bylo pozorováno, které systémy a data mohou být postiženy a kdo musí být zapojen interně. Výsledkem je první písemný obraz situace s otevřenými otázkami.
- Zajištění stop a omezení: Logy, souborové systémy a databáze se zajistí dříve, než zasáhneme. Poté izolujeme postižené systémy, zablokujeme kompromitované přístupy a přerušíme rozpoznatelná spojení útočníka.
- Odstranění: Uzavřeme vstupní bránu, například záplatováním na opravené verze PHP a restartem všech workerů, odstraníme zadní vrátka a vyměníme tajné údaje. Pro podrobnou analýzu v případě potřeby přizveme specializované partnery pro IT forenzní analýzu.
- Obnova: Systémy se kontrolovaně vracejí do provozu, pokud možno z čistých zdrojů nebo na nově nasazených serverech. Poté je zvýšeně sledujeme, zda se znovu neobjeví nesrovnalosti.
- Vyhodnocení: Obdržíte závěrečnou zprávu s časovou osou, příčinami, opatřeními a doporučeními. Společně zaznamenáme, co má příště jít rychleji.
Uchovejte logy serveru a neměňte žádné systémy, dokud není vše zajištěno. U PHP2Shell BSI (německý Spolkový úřad pro informační bezpečnost) doporučuje webové servery, které nelze okamžitě záplatovat, dočasně odpojit od sítě.
Role a komunikace během incidentu
Incident potřebuje jasné odpovědnosti. Osvědčil se malý okruh: osoba s pravomocí rozhodovat, technický kontakt na vaší straně a my jako technické vedení. Porady k situaci se konají v pevných intervalech, výsledky se zaznamenávají písemně.
Souběžně běží úkoly, které nepřebíráme, ale pro které dodáváme fakta: posouzení oznamovací povinnosti podle GDPR do 72 hodin, informování pojišťovny, případné trestní oznámení a krizová komunikace vůči zákazníkům a partnerům.
Co potřebujeme od vás a co získáte
Potřebujeme administrátorské přístupy k postiženým systémům, přehled infrastruktury a dodavatelů, osobu s pravomocí rozhodovat a ochotu systémy podle potřeby dočasně vypnout. Užitečné jsou existující nouzové plány, schémata sítě a zálohy s datem.
Získáte průběžný protokol incidentu, pravidelné obrazy situace srozumitelným jazykem, závěrečnou zprávu pro vedení, pověřence pro ochranu osobních údajů a pojišťovnu a prioritizovaný seznam zlepšení. Jak se na příští incident připravit lépe, popisuje stránka Sestavení IT nouzového plánu pro webové servery.
Typické chyby v prvních hodinách
Mnoho incidentů se zhorší, protože se v rozrušení dobře míněné kroky provedou ve špatném pořadí. Tyto vzorce vidíme často:
- Okamžitě nasadit znovu: Server se smaže a nainstaluje znovu dřív, než bylo cokoli zajištěno. Poté už nelze objasnit, zda unikla data.
- Měnit hesla z napadeného systému: Pokud má útočník stále přístup, vidí nová hesla také.
- Smazat jen viditelný soubor: Webshell je pryč, druhá zadní vrátka v cron úloze zůstávají.
- Záplatovat bez restartu: Nové soubory PHP leží na disku, staří workeři dál běží v paměti.
- Nikdo nevede protokol: Později nikdo neví, kdo kdy co změnil. To ztěžuje jednání s pojišťovnou a úřady.
Sladěný postup těmto chybám brání, aniž by zdržoval omezení škod.
Co neslibujeme
Neslibujeme, že bude každý incident zcela objasněn; bez stop zůstanou otázky otevřené a tak to také napíšeme do zprávy. Neposkytujeme právní poradenství ani výroky o odpovědnosti či pojistné ochraně. Naším cílem je jasný konec: na incidentu pracujeme, dokud není uzavřen a zdokumentován.
Časté dotazy
Jaký je rozdíl mezi reakcí na incidenty a IT forenzní analýzou?
Cílem reakce na incidenty je incident omezit a bezpečně obnovit provoz. IT forenzní analýza podrobně a důkazně objasňuje, co se stalo. V praxi do sebe obojí zapadá, forenzní analýza často zajišťuje stopy souběžně.
Kdy bych měl přizvat dodavatele reakce na incidenty?
Jakmile vznikne podezření, že měl útočník přístup k systémům a rozsah nedokážete spolehlivě odhadnout. Čím dříve začne zajišťování stop, tím více lze později doložit.
Kdo během incidentu rozhoduje?
Rozhodnutí děláte vy, například o vypnutích, komunikaci nebo hlášeních. My připravíme technické podklady, ukážeme možnosti s jejich důsledky a rozhodnutí provedeme.
Musím přizvat policii?
Trestní oznámení je v mnoha případech smysluplné a pro některé pojišťovny důležité. Příslušná jsou ústřední kontaktní místa německé policie pro kybernetickou kriminalitu (ZAC). Zda a kdy oznámení podáte, rozhodněte s právníkem.