przywrócenie działania

Przywrócenie działania (recovery) to etap reagowania na incydenty, w którym systemy wracają do normalnej pracy, a obrońcy pod wzmożonym monitoringiem sprawdzają, czy napastnik nie odzyskał dostępu. Według NIST administratorzy przywracają wtedy systemy do normalnego działania, potwierdzają, że działają poprawnie, i w razie potrzeby usuwają podatności, by zapobiec podobnym incydentom ^[1]. W polskich tekstach o zarządzaniu incydentami etap ten opisuje się jako przywracanie systemów do stanu poprawnego funkcjonowania, czyli zabezpieczenie ciągłości działania ^[6].

Miejsce w procesie

Przywrócenie następuje po opanowaniu incydentu i usunięciu zagrożenia. NIST zaznacza, że w niektórych incydentach usuwanie nie jest potrzebne albo odbywa się w trakcie przywracania ^[1]. Kolejność ma znaczenie: odtworzenie systemu, zanim usunięto przyczynę, zwykle kończy się ponownym włamaniem tą samą drogą.

RYS. 1Od opanowania do normalnej pracy

Działania

NIST wymienia działania typowe dla tego etapu ^[1].

Częścią przywracania jest zwykle podniesienie poziomu logowania i monitoringu sieci ^[1]. NIST uzasadnia to tym, że zasób raz skutecznie zaatakowany często jest atakowany ponownie, a inne zasoby organizacji bywają atakowane w podobny sposób ^[1]. Dlatego samo „strona znowu działa” nie kończy etapu.

Przy dużych incydentach przywracanie może trwać miesiące ^[1]. NIST zaleca podejście etapowe: najpierw szybkie zmiany o dużej wartości, wprowadzane w ciągu dni lub tygodni, później zmiany długofalowe, np. w infrastrukturze ^[1].

Planowanie

Przywrócenie jest szybsze, jeśli zaplanowano je przed incydentem. NIST poświęcił temu osobną publikację SP 800-184 z grudnia 2016 roku ^[2]. Dokument zaleca, by zarządzanie ryzykiem obejmowało pełne planowanie przywracania, a zidentyfikowanie i uszeregowanie zasobów organizacji pomagało tworzyć skuteczne plany i realistyczne scenariusze testów ^[2]. Zaleca też ciągłe doskonalenie planów na podstawie wniosków z wcześniejszych zdarzeń, także w innych organizacjach ^[2].

W praktyce plan odpowiada na kilka pytań. Które systemy wracają pierwsze? Ile danych można stracić i jak długo system może nie działać? Te dwie wartości opisują wskaźniki RPO i RTO. Plan jest częścią szerszego planu ciągłości działania, a odtwarzanie całej infrastruktury po poważnej awarii nazywa się disaster recovery (DR).

W WordPressie

Dokumentacja WordPress.org opisuje kolejne kroki po włamaniu na stronę ^[3]. Do etapu przywracania należą:

• Odtworzenie z kopii. Jeśli istnieje kopia zapasowa (backup), można ją odtworzyć i przejść do analizy ^[3]. Przed czyszczeniem zaleca się jednak zapisać jeszcze jedną kopię, nawet zainfekowaną, jako punkt odniesienia na wypadek poważnej awarii ^[3].
• Podmiana plików rdzenia. Katalogi /wp-admin i /wp-includes można bezpiecznie zastąpić świeżymi, w tej samej wersji, którą strona używa ^[3]. Dokumentacja odradza reinstalację z panelu, bo instalator zwykle tylko nadpisuje istniejące pliki, a włamania często dodają nowe ^[3].
• Przegląd wp-content i .htaccess. Motywy i wtyczki wymagają staranniejszego przeglądu, a plik .htaccess jest jednym z najczęściej zmienianych przez napastników ^[3].
• Aktualizacja. Po oczyszczeniu instalację należy zaktualizować, bo starsze wersje są bardziej podatne na włamania ^[3].
• Ponowna zmiana haseł. Hasła zmienia się jeszcze raz po upewnieniu się, że strona jest czysta; warto zmienić też użytkownika i hasło bazy danych w wp-config.php ^[3].
• Kontrola kont. Nowi, nieznani użytkownicy to jeden ze wskaźników włamania ^[3]. Jeśli napastnik przejął konto administratora, dostęp można odzyskać przez reset hasła albo bezpośrednio w tabeli wp_users za pomocą narzędzia do bazy danych udostępnianego przez hosting ^[3].
• Porównanie z wzorcem. Przy kontroli wersji można szybko ustalić, co się zmieniło, i wrócić do poprzedniej wersji; pliki można też porównać z wersjami z oficjalnego repozytorium WordPressa ^[3].
• Utwardzenie. Na koniec dokumentacja odsyła do zaleceń utwardzania WordPressa ^[3].

Szczegółowo proces opisuje hasło czyszczenie przejętej strony.

Warunkiem jest sprawna kopia. Kopia strony WordPress składa się z bazy danych, zawierającej wpisy i komentarze, oraz z plików: rdzenia, motywów, wtyczek, katalogu uploads, wp-config.php i .htaccess ^[4]. Dokumentacja zaleca trzymać co najmniej 3 do 5 ostatnich kopii w różnych miejscach, np. na serwerze, w chmurze i na komputerze lokalnym ^[4]. Kopie automatyczne warto co jakiś czas uzupełnić ręczną, by upewnić się, że proces działa ^[4]. Kopia przechowywana tylko na tym samym serwerze może zniknąć razem z nim; ochronę przed usunięciem przez napastnika daje kopia niezmienna (immutable backup).

Koszty i przykłady

Przywracanie bywa najdroższą częścią incydentu. W lutym 2003 roku CERT Polska przytoczył szacunki strat po epidemii robaka Slammer: firma Mi2g podała od 950 mln do 1,2 mld USD, a Computer Economics od 750 mln do 1 mld USD ^[5]. W drugim z tych szacunków suma dotyczyła głównie kosztów przywrócenia systemów do prawidłowego działania ^[5]. Przy ransomware od dostępności czystych kopii zależy, czy przywrócenie jest w ogóle możliwe bez udziału napastnika.

Po przywróceniu przychodzi czas na wnioski. NIST zaleca spotkanie podsumowujące w ciągu kilku dni od zakończenia incydentu ^[1]; zob. post-incident review.