Kopia zapasowa jest dostępna, a administrator potrafi z niej przywrócić serwer. To ważna informacja, lecz jeszcze nie odpowiedź na pytanie, czy firma może bezpiecznie wrócić do normalnej pracy. Trzeba ustalić, co zostanie odtworzone, w jakim środowisku i z jakimi zależnościami. Równolegle ktoś musi zdecydować, które procesy mają pierwszeństwo i kto potwierdzi, że można ponownie dopuścić do nich użytkowników.

Zacznijcie od usługi potrzebnej firmie

Lista najważniejszych serwerów pomaga zespołowi technicznemu, ale priorytety odtworzenia warto opisać również językiem pracy przedsiębiorstwa. Czy najpierw potrzebna jest realizacja już przyjętych zamówień, obsługa nowych zgłoszeń, czy dostęp do dokumentacji? Odpowiedź powinni uzgodnić właściciele procesów z IT i osobami zarządzającymi incydentem. Najgłośniejsze zgłoszenie nie musi oznaczać najważniejszej zależności.

Wyobraźmy sobie, że firma chce uruchomić sprzedaż, lecz magazyn nie ma jeszcze dostępu do stanów i dokumentów wysyłkowych. Samo otwarcie formularza zamówienia nie przywraca wtedy całego procesu. Warto sprawdzić, jakie systemy, konta, połączenia i osoby są potrzebne do wykonania zadania od początku do końca. Ten przykład pokazuje, dlaczego kolejności odtwarzania nie powinno ustalać się wyłącznie według łatwości uruchomienia aplikacji.

Przy każdej usłudze zapiszcie minimalny zakres działania, który ma zostać przywrócony. Pozwoli to odróżnić kontrolowany start części funkcji od ogólnej deklaracji, że „wszystko już działa”.

Nie przywracajcie dostępu sprawcy razem z danymi

Odtwarzanie trzeba skoordynować z ograniczeniem incydentu i usunięciem mechanizmów, które umożliwiły nieuprawniony dostęp. Jeżeli atakujący nadal może korzystać z przejętych kont lub pozostawionych narzędzi, odtworzone środowisko może ponownie zostać naruszone. Nie należy więc traktować przywrócenia plików jako zamiennika analizy i działań naprawczych.

Przed rozpoczęciem uzgodnijcie kilka kwestii:

• Kto ocenia, czy warunki pozwalają rozpocząć odtwarzanie wybranego zakresu?
• Jakie elementy środowiska wymagają odbudowy, aktualizacji lub zmiany konfiguracji?
• Które konta i uprawnienia trzeba sprawdzić przed dopuszczeniem użytkowników?
• Jak zostaną zachowane materiały potrzebne do analizy incydentu?
• Czy środowisko odtwarzania jest oddzielone od elementów, którym nadal nie można ufać?

Szczegóły działań zależą od rodzaju zdarzenia i architektury. W jednym przypadku wystarczy odtworzenie określonych danych po naprawie środowiska, w innym potrzebna będzie jego odbudowa. Decyzję powinny podejmować osoby mające wyniki analizy oraz odpowiednie kompetencje. Uniwersalne polecenie „przywróćcie ostatnią kopię” pomija te różnice.

Nie warto także nakazywać samodzielnego czyszczenia urządzeń przez wszystkich pracowników. Zespół prowadzący incydent powinien określić sposób postępowania i zabezpieczenia informacji. Nieskoordynowane działania mogą utrudnić ustalenie, co się wydarzyło, oraz sprawdzenie skuteczności napraw.

Sprawdźcie kopię i zakres brakujących danych

Komunikat o pomyślnym wykonaniu kopii nie jest równoznaczny z potwierdzeniem udanego odtworzenia. Potrzebna jest weryfikacja, czy kopia jest dostępna, obejmuje wymagane elementy i nadaje się do wykorzystania w danej sytuacji. Zależnie od systemu znaczenie mają nie tylko dokumenty, ale też bazy danych, konfiguracja i składniki potrzebne aplikacji. Zakres sprawdzenia powinien wynikać z planu odtworzenia oraz analizy incydentu.

Szczególnie ważny jest moment, z którego pochodzą dane. Najnowsza kopia nie musi być właściwym wyborem, jeżeli mogła już obejmować zmiany wprowadzone przez atakującego. Z drugiej strony starsza wersja może nie zawierać ostatnich operacji biznesowych. Tę różnicę trzeba przedstawić osobom decydującym o wznowieniu pracy.

Przygotujcie prosty opis luki: jakie operacje wykonano po punkcie odtworzenia i skąd można uzyskać wiarygodne informacje do ich odtworzenia lub uzgodnienia. Nie należy obiecywać odzyskania wszystkich zmian tylko dlatego, że istnieje kopia z wcześniejszego dnia.

Przykładowo część zleceń mogła zostać przyjęta telefonicznie podczas przestoju. Po uruchomieniu aplikacji potrzebna jest osoba odpowiedzialna za wprowadzenie ich w kontrolowany sposób i sprawdzenie, czy nie powstaną duplikaty. To zadanie organizacyjne, którego administrator nie rozwiąże samym przywróceniem bazy.

Umówcie warunki uruchomienia, zanim zabrzmi „gotowe”

Odbiór techniczny i potwierdzenie użyteczności biznesowej powinny się uzupełniać. IT może sprawdzić działanie aplikacji, uprawnienia i monitorowanie, a przedstawiciel danego procesu wykonać uzgodnione zadania kontrolne. Zakres takich prób trzeba dopasować do systemu i ryzyka. Nie ma jednej liczby testów, która automatycznie potwierdza bezpieczeństwo każdego środowiska.

Warto zawczasu uzgodnić:

• Jakie funkcje muszą działać przed dopuszczeniem pierwszej grupy użytkowników?
• Kto potwierdzi spójność i przydatność odtworzonych danych?
• Jakie ograniczenia pozostaną po uruchomieniu i kto przekaże je zespołowi?
• Jakie sygnały spowodują zatrzymanie działania lub ponowne ograniczenie dostępu?
• Kto zatwierdza kolejny etap i gdzie zapisuje uzasadnienie decyzji?

Przy większym zakresie można rozważyć stopniowe przywracanie usług lub dostęp wybranej grupy użytkowników, o ile pozwalają na to warunki techniczne i bezpieczeństwo. Taki start wymaga jednak jasnych zasad. Użytkownicy muszą wiedzieć, czy ich działania są już normalnymi operacjami firmy, czy nadal kontrolowaną próbą. Inaczej testowe zamówienie może zostać potraktowane jak rzeczywiste zlecenie wysyłki.

Odtworzenie systemów jest tylko jednym z obszarów odpowiedzialności podczas incydentu. Szerszy kontekst decyzji kierownictwa opisuje tekst: https://biznes.interia.pl/artykul-sponsorowany/news-cyberatak-w-firmie-co-musi-zrobic-zarzad,nId,23570196. Plan techniczny warto powiązać z ustaleniami dotyczącymi komunikacji, zobowiązań wobec partnerów i oceny obowiązków formalnych.

Po starcie nadal potrzebny jest nadzór

Uruchomienie usługi nie kończy obserwacji środowiska. Zespół powinien wiedzieć, kto sprawdza sygnały możliwego nawrotu problemu, kto przyjmuje zgłoszenia użytkowników i kiedy ocenia wyniki pierwszego etapu. Należy też potwierdzić działanie kopii zapasowych w przywróconym środowisku. Tymczasowe rozwiązania wdrożone podczas naprawy wymagają wskazania właściciela i terminu przeglądu.

Zarząd potrzebuje przy tym informacji o pozostałych ograniczeniach, a nie tylko wiadomości o uruchomieniu serwera. Jeśli część funkcji jest wyłączona, dane obejmują wcześniejszy stan lub obsługa wymaga dodatkowej kontroli, powinno to znaleźć się w uzgodnionym komunikacie dla właściwych odbiorców.

Po zakończeniu najbardziej pilnych prac porównajcie plan z rzeczywistym przebiegiem odtworzenia. Wybierzcie konkretne poprawki: brakujący element kopii, nieznaną zależność, niedostępny kontakt do dostawcy albo niejasne uprawnienie do podjęcia decyzji. Każda poprawka powinna mieć osobę odpowiedzialną i sposób sprawdzenia jej wykonania. Dzięki temu wnioski z incydentu trafią do następnego testu, zamiast pozostać wyłącznie w protokole spotkania.

Wpis gościnny