Röviden: Ha egy támadás egynél több weboldalt érint, olyan incident response szolgáltatóra van szüksége, aki strukturáltan kezeli az incidenst. Átvesszük a helyzetkép felvételét, a megfékezést, a tisztítást és a biztonságos helyreállítást, egyértelmű szerepekkel és hézagmentes dokumentációval. A döntések Önnél maradnak, mi a technikai alapot biztosítjuk.
Mit jelent az incident response szerver elleni támadásoknál
Az incident response egy biztonsági incidens rendezett kezelése. Kapkodó egyedi akciók helyett a munka rögzített fázisokat követ: felismerés és besorolás, megfékezés, elhárítás, helyreállítás, utólagos feldolgozás. Minden intézkedést időponttal és indoklással rögzítenek.
Éppen webszervereknél ez fontos. Egy PHP-alkalmazásokat futtató szerveren gyakran ott vannak az adatbázisok, a fizetési szolgáltatók, a levelezőszerverek és az interfészek hozzáférési adatai. Aki oda behatolt, tovább tud haladni. A PHP2Shell utáni helyzet megmutatja, milyen gyorsan állhat elő ilyen szituáció: hitelesítés nélküli kódfuttatás, a Unit 42 szerint több mint 22,6 millió kitett példány, és nincsenek közzétett, megerősített Indicators of Compromise.
Mikor van szüksége incident response szolgáltatóra
- több szerver vagy alkalmazás érintett, vagy érintett lehet
- felmerül a gyanú, hogy személyes adatok vagy fizetési adatok szivárogtak ki
- a támadó esetleg még aktív, például futó kapcsolatok vagy új fiókok révén
- zsarolás vagy a támadás nyilvános bejelentése történt
- a biztosító, a hatóságok vagy az üzleti partnerek dokumentált folyamatot várnak
Egyetlen megfertőzött weboldalnál gyakran elég a feltört weboldal esetén nyújtott vészhelyzeti segítség. Az átmenetet a teljes incidenskezelésre megbeszéljük Önnel, amint nagyobb kiterjedés rajzolódik ki.
Hogyan segít konkrétan a PHP SOS?
- Triázs és helyzetkép: Tisztázzuk, mit észleltek, mely rendszerek és adatok lehetnek érintettek, és kit kell belsőleg bevonni. Az eredmény egy első, írásos helyzetkép a nyitott kérdésekkel.
- Nyomok mentése és megfékezés: A naplókat, fájlrendszereket és adatbázisokat elmentjük, mielőtt beavatkoznánk. Ezután elszigeteljük az érintett rendszereket, zároljuk a kompromittált hozzáféréseket, és megszakítjuk a támadó felismerhető kapcsolatait.
- Elhárítás: Lezárjuk a behatolási pontot, például a javított PHP-verziókra való frissítéssel és az összes worker újraindításával, eltávolítjuk a hátsó ajtókat, és kicseréljük a titkokat. A részletes elemzéshez szükség esetén szakosodott partnereket vonunk be az IT-forenzikához.
- Helyreállítás: A rendszerek ellenőrzötten térnek vissza az üzembe, lehetőleg tiszta forrásokból vagy újonnan felállított szervereken. Utána fokozottan figyeljük őket az újabb feltűnő jelekre.
- Utólagos feldolgozás: Záró jelentést kap az idővonallal, az okokkal, az intézkedésekkel és a javaslatokkal. Közösen rögzítjük, minek kell legközelebb gyorsabban mennie.
Őrizze meg a szervernaplókat, és ne módosítson rendszereket, amíg nem készült mentés. A BSI PHP2Shell esetében azt ajánlja, hogy az azonnal nem javítható webszervereket átmenetileg vegyék le a hálózatról.
Szerepek és kommunikáció az incidens alatt
Egy incidenshez egyértelmű felelősségek kellenek. Bevált egy kis kör, amelyben van egy döntési jogkörrel rendelkező személy, egy műszaki kapcsolattartó az Ön oldaláról, és mi mint műszaki vezetés. A helyzetmegbeszélések rögzített időközönként zajlanak, az eredményeket írásban rögzítik.
Párhuzamosan olyan feladatok futnak, amelyeket nem mi veszünk át, de amelyekhez tényeket szolgáltatunk: a 72 órán belüli GDPR szerinti bejelentési kötelezettség vizsgálata, a biztosító tájékoztatása, egy lehetséges feljelentés, valamint az ügyfelek és partnerek felé irányuló válságkommunikáció.
Mire van szükségünk Öntől, és mit kap
Szükségünk van az érintett rendszerek rendszergazdai hozzáféréseire, az infrastruktúra és a szolgáltatók áttekintésére, egy döntési jogkörrel rendelkező személyre, és arra a készségre, hogy a rendszereket szükség esetén átmenetileg lekapcsolják. Hasznosak a meglévő vészhelyzeti tervek, hálózati vázlatok és a dátumozott mentések.
Folyamatos incidensnaplót, rendszeres, érthető nyelvű helyzetképeket, a vezetésnek, az adatvédelmi felelősöknek és a biztosítónak szóló záró jelentést, valamint a fejlesztések prioritási listáját kapja. Hogyan készülhet fel jobban a következő incidensre, azt az IT-vészhelyzeti terv készítése webszerverekhez írja le.
Tipikus hibák az első órákban
Sok incidens azért válik súlyosabbá, mert az izgalomban jó szándékú lépések rossz sorrendben történnek. Ezeket a mintákat gyakran látjuk:
- Azonnali újratelepítés: A szervert törlik és újratelepítik, mielőtt mentés készült volna. Utána már nem tisztázható, hogy szivárogtak-e ki adatok.
- Jelszavak módosítása a megfertőzött rendszerről: Ha a támadónak még van hozzáférése, látja az új jelszavakat is.
- Csak a látható fájl törlése: A webshell eltűnik, a cron-feladatban lévő második hátsó ajtó marad.
- Javítás újraindítás nélkül: Az új PHP-fájlok a lemezen vannak, a régi workerek tovább futnak a memóriában.
- Senki sem vezet jegyzőkönyvet: Később senki sem tudja, ki mikor mit módosított. Ez megnehezíti a biztosítóval és a hatóságokkal folytatott beszélgetéseket.
Egy összehangolt folyamat megakadályozza ezeket a hibákat, a megfékezés késleltetése nélkül.
Amit nem ígérünk
Nem ígérjük, hogy minden incidenst teljesen kivizsgálnak; nyomok nélkül kérdések maradnak nyitva, és ezt így is írjuk a jelentésbe. Nem adunk jogi tanácsot, és nem nyilatkozunk a felelősségről vagy a biztosítási fedezetről. A célunk egy világos lezárás: addig dolgozunk az incidensen, amíg le nem zárul és dokumentálva nincs.
Gyakori kérdések
Mi a különbség az incident response és az IT-forenzika között?
Az incident response célja az incidens megfékezése és az üzem biztonságos helyreállítása. Az IT-forenzika részletesen és bizonyíték értékűen tisztázza, mi történt. A gyakorlatban a kettő összekapcsolódik, a forenzika gyakran párhuzamosan menti a nyomokat.
Mikor érdemes incident response szolgáltatót bevonni?
Amint felmerül a gyanú, hogy egy támadó hozzáfért rendszerekhez, és Ön nem tudja biztosan felmérni a mértékét. Minél korábban kezdődik a nyomok mentése, annál több igazolható később.
Ki dönt az incidens alatt?
A döntéseket Ön hozza, például a lekapcsolásról, a kommunikációról vagy a bejelentésekről. Mi előkészítjük a technikai alapokat, megmutatjuk a lehetőségeket következményeikkel együtt, és végrehajtjuk a döntéseket.
Be kell vonnom a rendőrséget?
A feljelentés sok esetben hasznos, és egyes biztosításoknál lényeges. Erre a német rendőrség kiberbűnözési központi kapcsolattartó pontjai (Zentrale Ansprechstellen Cybercrime, ZAC) illetékesek. Hogy feljelent-e, és mikor, azt az ügyvédjével együtt dönti el.