Krótko: Jeśli atak dotyczy więcej niż jednej strony, potrzebują Państwo usługodawcy Incident Response, który uporządkowanie obsłuży incydent. Przejmujemy obraz sytuacji, powstrzymanie, oczyszczanie i bezpieczne przywrócenie działania, z jasnymi rolami i pełną dokumentacją. Decyzje pozostają po Państwa stronie, my zapewniamy podstawę techniczną.
Co oznacza Incident Response przy atakach na serwery
Incident Response to uporządkowana obsługa incydentu bezpieczeństwa. Zamiast gorączkowych pojedynczych działań praca przebiega według stałych faz: rozpoznać i sklasyfikować, powstrzymać, usunąć, przywrócić, podsumować. Każdy środek jest odnotowywany wraz z czasem i uzasadnieniem.
Szczególnie przy serwerach WWW ma to znaczenie. Serwer z aplikacjami PHP zawiera często dane dostępowe do baz danych, operatorów płatności, serwerów pocztowych i interfejsów. Kto się tam włamał, może przemieszczać się dalej. Sytuacja po PHP2Shell pokazuje, jak szybko może powstać taka sytuacja: nieuwierzytelnione wykonanie kodu, ponad 22,6 miliona wystawionych instancji według Unit 42 i brak opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise).
Kiedy potrzebują Państwo usługodawcy Incident Response
- dotknięte są lub mogą być dotknięte kilka serwerów lub aplikacji
- istnieje podejrzenie wycieku danych osobowych lub danych płatniczych
- atakujący może być jeszcze aktywny, na przykład przez trwające połączenia lub nowe konta
- pojawił się szantaż lub publiczna zapowiedź ataku
- ubezpieczyciel, organy lub partnerzy biznesowi oczekują udokumentowanego przebiegu
Przy pojedynczej zainfekowanej stronie często wystarcza pomoc awaryjna przy zhakowanej stronie. Przejście do pełnej obsługi incydentu omawiamy z Państwem, gdy tylko zarysuje się większy zakres.
Jak konkretnie pomaga PHP SOS?
- Triage i obraz sytuacji: Ustalamy, co zaobserwowano, które systemy i dane mogą być dotknięte oraz kogo trzeba zaangażować wewnętrznie. Wynikiem jest pierwszy, pisemny obraz sytuacji z otwartymi pytaniami.
- Zabezpieczenie śladów i powstrzymanie: Logi, systemy plików i bazy danych są zabezpieczane, zanim zaingerujemy. Następnie izolujemy dotknięte systemy, blokujemy przejęte dostępy i przerywamy rozpoznawalne połączenia atakującego.
- Usunięcie: Zamykamy drogę włamania, na przykład przez łatanie do naprawionych wersji PHP i restart wszystkich workerów, usuwamy tylne furtki i wymieniamy sekrety. Do szczegółowej analizy w razie potrzeby angażujemy wyspecjalizowanych partnerów od informatyki śledczej.
- Przywrócenie: Systemy wracają do pracy w sposób kontrolowany, w miarę możliwości z czystych źródeł lub na nowo postawionych serwerach. Następnie nadzorujemy je ze zwiększoną uwagą pod kątem ponownych nieprawidłowości.
- Podsumowanie: Otrzymują Państwo raport końcowy z osią czasu, przyczynami, środkami i zaleceniami. Wspólnie ustalamy, co następnym razem ma pójść szybciej.
Proszę zachować logi serwera i nie zmieniać systemów, zanim nie zostaną zabezpieczone. Przy PHP2Shell BSI zaleca czasowe odłączenie od sieci serwerów WWW, których nie da się od razu załatać.
Role i komunikacja w trakcie incydentu
Incydent wymaga jasnych odpowiedzialności. Sprawdza się niewielki zespół złożony z osoby uprawnionej do decyzji, technicznej osoby kontaktowej po Państwa stronie i nas jako kierownictwa technicznego. Odprawy dotyczące sytuacji odbywają się w stałych odstępach, a wyniki są odnotowywane na piśmie.
Równolegle toczą się zadania, których nie przejmujemy, ale dla których dostarczamy fakty: ocena obowiązku zgłoszenia na podstawie RODO w ciągu 72 godzin, poinformowanie ubezpieczyciela, ewentualne zawiadomienie oraz komunikacja kryzysowa wobec klientów i partnerów.
Czego potrzebujemy od Państwa i co otrzymują Państwo
Potrzebujemy dostępów administracyjnych do dotkniętych systemów, przeglądu infrastruktury i usługodawców, osoby uprawnionej do decyzji oraz gotowości do czasowego wyłączenia systemów w razie potrzeby. Pomocne są istniejące plany awaryjne, szkice sieci i kopie zapasowe z datą.
Otrzymują Państwo bieżący protokół incydentu, regularne obrazy sytuacji w zrozumiałym języku, raport końcowy dla zarządu, inspektora ochrony danych i ubezpieczyciela oraz listę ulepszeń z priorytetami. Jak lepiej przygotować się na kolejny incydent, opisuje strona Opracowanie planu awaryjnego IT dla serwerów WWW.
Typowe błędy w pierwszych godzinach
Wiele incydentów staje się cięższych, ponieważ w pośpiechu dobrze zamierzone kroki wykonywane są w niewłaściwej kolejności. Te wzorce widzimy często:
- Natychmiastowa ponowna instalacja: Serwer jest kasowany i instalowany od nowa, zanim wykonano kopię zabezpieczającą. Potem nie da się już wyjaśnić, czy dane wyciekły.
- Zmiana haseł z zainfekowanego systemu: Jeśli atakujący nadal ma dostęp, widzi też nowe hasła.
- Usunięcie tylko widocznego pliku: Webshell znika, druga tylna furtka w zadaniu cron pozostaje.
- Łatanie bez restartu: Nowe pliki PHP leżą na dysku, a stare workery nadal działają w pamięci.
- Nikt nie prowadzi protokołu: Później nikt nie wie, kto i kiedy co zmienił. Utrudnia to rozmowy z ubezpieczycielem i organami.
Uzgodniony przebieg zapobiega tym błędom, nie opóźniając powstrzymania ataku.
Czego nie obiecujemy
Nie obiecujemy, że każdy incydent zostanie w pełni wyjaśniony; bez śladów pewne pytania pozostają otwarte i tak zapisujemy to w raporcie. Nie udzielamy porad prawnych ani nie wypowiadamy się w kwestii odpowiedzialności czy ochrony ubezpieczeniowej. Naszym celem jest jasne zakończenie: pracujemy nad incydentem, aż zostanie zamknięty i udokumentowany.
Częste pytania
Jaka jest różnica między Incident Response a informatyką śledczą?
Celem Incident Response jest powstrzymanie incydentu i bezpieczne przywrócenie działania. Informatyka śledcza wyjaśnia szczegółowo i w sposób zabezpieczający dowody, co się stało. W praktyce oba obszary zazębiają się, a informatyka śledcza często zabezpiecza ślady równolegle.
Kiedy powinienem zaangażować usługodawcę Incident Response?
Gdy tylko pojawi się podejrzenie, że atakujący miał dostęp do systemów, a nie mogą Państwo pewnie ocenić zakresu. Im wcześniej rozpocznie się zabezpieczanie śladów, tym więcej da się później udowodnić.
Kto podejmuje decyzje w trakcie incydentu?
Decyzje podejmują Państwo, na przykład o wyłączeniach, komunikacji lub zgłoszeniach. My przygotowujemy podstawy techniczne, pokazujemy opcje wraz z ich skutkami i wdrażamy decyzje.
Czy muszę angażować policję?
Zawiadomienie jest w wielu przypadkach sensowne i dla niektórych ubezpieczycieli istotne. Za to odpowiadają centralne punkty kontaktowe ds. cyberprzestępczości policji. Czy i kiedy złożyć zawiadomienie, decydują Państwo wraz z prawnikiem.