Obowiązek informacyjny rodo
W poprzednim artykule omówiliśmy drogę od incydentu do zgłoszenia. Organizacja rozpoznała problem, oceniła jego znaczenie, uruchomiła ścieżkę eskalacji i przekazała pierwsze informacje do właściwego CSIRT. Wysłanie zgłoszenia nie oznacza jednak, że sytuacja została opanowana. To dopiero moment, w którym rozpoczyna się najważniejsza część pracy: ograniczenie skutków incydentu, ustalenie jego przyczyny i bezpieczne przywrócenie działalności.
Podczas incydentu czas ma ogromne znaczenie, ale szybkość nie powinna oznaczać chaosu. Każda decyzja może wpłynąć na skalę szkód, możliwość odtworzenia przebiegu zdarzenia oraz czas potrzebny do wznowienia pracy. Dlatego procedura obsługi incydentu nie może kończyć się na informacji, komu należy zgłosić problem. Powinna prowadzić organizację przez kolejne działania aż do momentu, w którym można bezpiecznie uznać sprawę za zamkniętą.
Pierwszym celem po potwierdzeniu incydentu jest zatrzymanie jego dalszego rozwoju. Nie zawsze oznacza to natychmiastowe wyłączenie całej infrastruktury. Reakcja powinna być dopasowana do rodzaju zdarzenia, jego zasięgu oraz znaczenia dotkniętych nim systemów dla działalności organizacji.
Jeżeli doszło do przejęcia konta użytkownika, konieczne może być zablokowanie dostępu, zakończenie aktywnych sesji i zmiana danych uwierzytelniających. W przypadku podejrzenia zainfekowania urządzenia właściwym działaniem może być odizolowanie go od sieci. Jeśli zagrożenie obejmuje większą część środowiska, czasem trzeba podjąć decyzję o czasowym zatrzymaniu wybranych usług.
Takie decyzje nie powinny zależeć wyłącznie od osoby, która jako pierwsza zauważyła problem. Organizacja musi wcześniej ustalić, kto może zatwierdzić odłączenie systemu, zatrzymanie usługi lub uruchomienie planu awaryjnego. Zbyt późna reakcja może zwiększyć skalę szkód. Z kolei działanie nieprzemyślane może zatrzymać kluczowe procesy, doprowadzić do utraty danych albo zniszczyć informacje potrzebne do wyjaśnienia sprawy.
Naturalnym odruchem po wykryciu incydentu jest chęć jak najszybszego usunięcia problemu. Administrator może chcieć skasować podejrzany plik, ponownie uruchomić urządzenie, przywrócić system z kopii zapasowej albo od razu przeprowadzić pełną reinstalację. Takie działania mogą okazać się potrzebne, ale wykonane zbyt wcześnie utrudnią ustalenie, co faktycznie się wydarzyło.
Przed rozpoczęciem naprawy należy więc zabezpieczyć dostępne informacje. Znaczenie mogą mieć logi systemowe, wiadomości e-mail, zrzuty ekranów, historia logowania, dane z narzędzi monitorujących, informacje o aktywnych połączeniach, podejrzane pliki oraz zapis czynności wykonywanych przez zespół.
Nie oznacza to, że każdy pracownik powinien samodzielnie prowadzić analizę informatyki śledczej. Zadaniem osoby, która zauważyła problem, jest przede wszystkim niepogarszanie sytuacji i szybkie przekazanie informacji. Zabezpieczaniem materiału powinny zajmować się osoby posiadające odpowiednie kompetencje i uprawnienia.
Bardzo pomocna jest również prosta oś czasu incydentu. Powinna wskazywać, kiedy wykryto problem, kto otrzymał informację, jakie decyzje podjęto oraz jakie działania wykonano. Dzięki temu organizacja może później odtworzyć przebieg wydarzeń, porównać ustalenia poszczególnych osób i przygotować spójne informacje dla kierownictwa, CSIRT lub innych uprawnionych podmiotów.
Zablokowanie konta, usunięcie złośliwego pliku lub ponowne uruchomienie systemu może przywrócić chwilową stabilność. Nie daje jednak pewności, że zagrożenie rzeczywiście zostało wyeliminowane. Jeśli organizacja ograniczy się do usunięcia widocznych skutków, ten sam problem może pojawić się ponownie.
Dlatego po opanowaniu najpilniejszej części sytuacji należy ustalić przyczynę źródłową incydentu. Trzeba zrozumieć, w jaki sposób doszło do zdarzenia, dlaczego istniejące zabezpieczenia mu nie zapobiegły i dlaczego problem nie został wykryty wcześniej.
Przyczyną może być podatność w oprogramowaniu, błędna konfiguracja, brak aktualizacji, nadmierne uprawnienia, przejęte dane logowania, niewłaściwa procedura albo problem po stronie dostawcy. Dopiero po ustaleniu przyczyny można dobrać działania naprawcze, które ograniczą ryzyko powtórzenia się podobnego incydentu.
Gdy zagrożenie zostało ograniczone, rozpoczyna się przywracanie systemów i procesów. Nie wszystkie usługi powinny jednak wracać do pracy jednocześnie. Kolejność musi wynikać z ich znaczenia dla działalności oraz zależności pomiędzy poszczególnymi elementami środowiska.
W tym miejscu szczególnego znaczenia nabierają plany ciągłości działania i odtwarzania po awarii. Powinny wskazywać, które procesy i systemy należy przywrócić najpierw, jakie zasoby są do tego potrzebne i kto podejmuje decyzję o wznowieniu działania.
Jeżeli organizacja korzysta z kopii zapasowej, musi upewnić się, że pochodzi ona sprzed incydentu i nie zawiera tego samego zagrożenia. Samo uruchomienie systemu nie wystarcza. Trzeba jeszcze sprawdzić poprawność jego działania, kompletność i integralność danych, konfigurację zabezpieczeń oraz brak dalszych oznak nieautoryzowanej aktywności.
Dopiero pozytywny wynik takiej weryfikacji powinien prowadzić do ponownego udostępnienia usługi użytkownikom.
Podczas obsługi incydentu różne osoby potrzebują różnych informacji. Zespół techniczny koncentruje się na zabezpieczeniu środowiska. Kierownictwo chce znać wpływ zdarzenia na działalność. Pracownicy potrzebują jasnej informacji, czy mogą korzystać z systemów. Pytania mogą również kierować klienci, dostawcy, ubezpieczyciel lub organy zewnętrzne.
Komunikacja nie może być pozostawiona przypadkowi. Organizacja powinna określić, kto odpowiada za informowanie poszczególnych grup, kto zatwierdza komunikaty i jaki zakres danych może zostać przekazany.
Wszystkie komunikaty powinny opierać się na potwierdzonych faktach. Zbyt wczesne wskazywanie przyczyny lub zapewnianie, że sytuacja została całkowicie opanowana, może później podważyć wiarygodność organizacji. Jednocześnie długotrwały brak informacji sprzyja niepewności, plotkom i nieskoordynowanym działaniom.
Obsługa techniczna, komunikacja oraz raportowanie powinny zatem przebiegać równolegle i korzystać z jednego, regularnie aktualizowanego obrazu sytuacji.
Powrót systemów do pracy nie oznacza automatycznie zakończenia incydentu. Przed jego formalnym zamknięciem trzeba potwierdzić, że przyczyna została usunięta, usługi działają prawidłowo, dane są kompletne, a dalsze monitorowanie nie wskazuje na utrzymywanie się zagrożenia.
Następnie należy wyciągnąć wnioski. Nie chodzi o znalezienie osoby, którą można obarczyć winą, lecz o określenie, co należy zmienić. Może to oznaczać poprawę konfiguracji, aktualizację procedur, zwiększenie zakresu monitoringu, przeprowadzenie dodatkowych szkoleń, zmianę wymagań wobec dostawcy albo aktualizację BCP i DRP.
Incydent powinien zostać uwzględniony także w rejestrze ryzyk. Jeżeli pokazał, że wcześniejsza ocena była zbyt niska lub zastosowane zabezpieczenia okazały się nieskuteczne, należy ponownie ocenić ryzyko i zaktualizować plan postępowania.
W ten sposób organizacja nie wraca po prostu do stanu sprzed incydentu. Wraca do działania lepiej przygotowana na kolejne zdarzenia.
Procedura obsługi incydentu nie jest instrukcją wyłącznie dla informatyków. To wspólny plan działania dla zespołu bezpieczeństwa, kierownictwa, komunikacji, compliance, IOD oraz właścicieli procesów biznesowych.
Jej skuteczność nie zależy od liczby stron, lecz od tego, czy w sytuacji presji organizacja wie, kto koordynuje działania, jakie informacje należy zabezpieczyć, jak ograniczyć skutki, w jakiej kolejności przywracać usługi i kto może zdecydować o formalnym zamknięciu incydentu.
Wcześniejszy artykuł pokazywał, jak przejść od incydentu do zgłoszenia. Ten wpis prowadzi organizację dalej: od zgłoszenia do opanowania sytuacji, bezpiecznego przywrócenia działalności i wdrożenia zmian ograniczających prawdopodobieństwo ponownego wystąpienia problemu.