„Nie działa system zamówień” i „atakujący ukradli bazę klientów” to dwa różne komunikaty. Pierwszy może opisywać zaobserwowany skutek, drugi wymaga dowodów dotyczących dostępu do danych. W pierwszych godzinach cyberincydentu raport dla zarządu powinien pomagać podejmować decyzje mimo brakujących informacji. Nie musi jeszcze zawierać pełnej rekonstrukcji ataku, ale powinien jasno pokazywać, co ustalono, co dopiero jest sprawdzane i kto odpowiada za następny krok.

Nadaj informacjom datę i określ ich zakres

Zacznij od godziny przygotowania aktualizacji i wskazania, jakiego środowiska dotyczy. Raport o jednym serwerze nie opisuje automatycznie stanu całej organizacji. Warto wymienić sprawdzone usługi oraz zaznaczyć obszary, których jeszcze nie oceniono. Dzięki temu zdanie „nie znaleziono nieprawidłowości” nie będzie odczytywane jako potwierdzenie bezpieczeństwa wszystkich systemów.

Rozdziel czas wystąpienia zdarzenia, pierwszego zauważonego sygnału i przekazania informacji zespołowi. Jeżeli któregoś momentu nie udało się ustalić, zapisz to wprost. Nie przypisuj godziny początku ataku wyłącznie na podstawie czasu, w którym pracownik zgłosił problem. To mogą być inne chwile, a rozbieżność jest ważna dla dalszej analizy.

Pokaż różnicę między obserwacją a hipotezą

Wyobraźmy sobie, że użytkownicy nie mogą otworzyć dokumentów, część plików ma zmienione rozszerzenia, a w katalogu pojawiła się notatka z żądaniem zapłaty. Tak można opisać obserwacje. Stwierdzenie, którędy sprawca dostał się do sieci i czy skopiował dane, powinno wynikać z odrębnej analizy. Nie należy dopisywać go tylko dlatego, że podobnie wyglądały inne znane incydenty.

Pomocne jest oznaczanie informacji jako potwierdzonej, roboczej albo wymagającej sprawdzenia. Przy hipotezie dopisz, na czym się opiera i jakie działanie może ją potwierdzić lub podważyć. Nie chodzi o tworzenie skomplikowanej skali pewności. Wystarczą krótkie, konsekwentnie stosowane określenia, zrozumiałe również dla osób spoza IT.

Brak potwierdzenia wycieku nie oznacza potwierdzenia, że wycieku nie było. W raporcie można zapisać, że zakres analizy nie pozwala jeszcze rozstrzygnąć tej kwestii.

Warto również unikać wskazywania winnego na podstawie pierwszego podejrzanego maila. Wiadomość może być ważnym śladem, ale jej obecność nie dowodzi, że właśnie ona rozpoczęła incydent. Raport operacyjny ma wspierać wyjaśnienie zdarzenia i ograniczanie szkód, a nie zastępować je szybką opowieścią o przyczynie.

Przełóż ustalenia techniczne na działanie firmy

Zarząd potrzebuje informacji o skutkach, które wymagają decyzji. Zamiast samej listy niedostępnych maszyn warto wskazać procesy: przyjmowanie zamówień, kompletowanie wysyłek, obsługę płatności lub dostęp do dokumentacji. Jeżeli istnieje obejście, opisz jego ograniczenia. Ręczne przyjmowanie zgłoszeń nie oznacza jeszcze, że firma może je sprawnie zrealizować i rozliczyć.

Krótki raport można oprzeć na następujących polach:

• Potwierdzony stan: co nie działa lub działa inaczej niż zwykle, z podaniem źródła i czasu obserwacji.
• Skutek biznesowy: które czynności są wstrzymane oraz jakie zależności utrudniają ich wznowienie.
• Działania w toku: kto realizuje zadanie i po czym będzie można poznać jego zakończenie.
• Niewiadome: czego jeszcze nie ustalono i kto prowadzi sprawdzenie.
• Decyzje potrzebne teraz: jakie warianty ma zatwierdzić uprawniona osoba oraz z jakimi ograniczeniami się one wiążą.
• Następna aktualizacja: kto ją przygotuje i jaki zakres informacji powinien uzupełnić.

Nie każdy szczegół wymaga przekazania na najwyższy poziom. Ścieżki plików, identyfikatory urządzeń czy surowe wyniki narzędzi można pozostawić w materiałach technicznych dostępnych właściwym osobom. W raporcie decyzyjnym wystarczy wyjaśnić ich znaczenie i wskazać, gdzie znajduje się materiał źródłowy. Nie należy przy tym przesyłać haseł, kluczy dostępu ani niepotrzebnych kopii danych klientów.

Szerszą perspektywę obowiązków i decyzji kierownictwa przedstawia artykuł: https://biznes.interia.pl/artykul-sponsorowany/news-cyberatak-w-firmie-co-musi-zrobic-zarzad,nId,23570196. Wewnętrzny raport powinien dostarczyć osobom odpowiedzialnym za ocenę prawną faktów potrzebnych do ich pracy, nie zastępować tej oceny własnym skrótem.

Zapisz, skąd pochodzi informacja

Przy ważnym ustaleniu odnotuj, czy wynika z logów, zgłoszenia użytkownika, rozmowy z dostawcą czy analizy specjalisty. Wstępna wiadomość od zewnętrznego operatora może zawierać zastrzeżenia, które znikają przy kolejnym przekazaniu. Dlatego warto zachować oryginalną treść w przeznaczonym do tego miejscu i odróżnić cytowane stanowisko dostawcy od własnych wniosków firmy.

Materiały techniczne należy zabezpieczać w sposób uzgodniony z zespołem prowadzącym incydent, dbając o ich pochodzenie i integralność. Odtwarzanie systemów, porządkowanie kont i analiza zdarzenia powinny być koordynowane. Samodzielne usuwanie plików lub czyszczenie historii tylko po to, by szybciej „zrobić porządek”, może pozbawić analizujących potrzebnych informacji.

Jeżeli dwa zespoły podają sprzeczne wyniki, nie wybieraj wersji wygodniejszej do przedstawienia. Zapisz rozbieżność i przydziel jej wyjaśnienie konkretnej osobie.

Nie obiecuj terminu bez pokazania założeń

Szacunek czasu przywrócenia usługi warto powiązać z warunkami: dostępnością odpowiedniej kopii, zakończeniem określonych sprawdzeń i gotowością systemów zależnych. Jeżeli któryś z tych elementów pozostaje nieznany, raport powinien to pokazywać. Precyzyjna godzina wpisana bez podstaw może zostać potraktowana jako zobowiązanie przez sprzedaż, obsługę klienta i partnerów.

Można zamiast tego przedstawić kolejny punkt kontrolny: po zakończeniu testu odtworzenia zespół zaktualizuje prognozę. To konkretna informacja o dalszym postępowaniu, nawet jeśli pełny termin powrotu do pracy nie jest jeszcze wiarygodny.

Zachowaj historię decyzji i korekt

Aktualizacja raportu nie powinna usuwać śladu wcześniejszych ustaleń. Wystarczy uzgodniony sposób wersjonowania, z godziną zmiany i informacją, co skorygowano. Jeśli początkowo podejrzewano jeden obszar, a później potwierdzono szerszy zasięg incydentu, wyjaśnij, jakie nowe dane doprowadziły do tej zmiany. Dzięki temu odbiorcy rozumieją rozwój wiedzy o zdarzeniu.

Osobno zapisz podjęte decyzje: kto je zatwierdził, na jakich informacjach się opierały i co ma zostać sprawdzone ponownie. Nie trzeba sporządzać rozbudowanego protokołu po każdej rozmowie. Krótka, uporządkowana notatka może wystarczyć do uniknięcia sytuacji, w której zespoły realizują sprzeczne polecenia lub nikt nie wie, czy wcześniejsze ograniczenie nadal obowiązuje. Po incydencie ten zapis pomoże także odtworzyć, gdzie zabrakło danych i co poprawić w następnym ćwiczeniu.

Materiał zewnętrzny