Opracowanie planu reagowania na incydenty od podstaw
Ostatnia aktualizacja:
6 czas czytania: 2 minuty
Kluczowe wnioski
- Przygotowanie decyduje o szybkości reakcji. Udokumentowany i przetestowany plan reagowania na incydenty pomaga zespołom działać szybko, zamiast improwizować w sytuacji kryzysowej.
- Należy opierać się na jasno określonych etapach reagowania. Przygotowanie, identyfikacja, powstrzymanie, likwidacja, przywrócenie stanu pierwotnego oraz wyciągnięte wnioski zapewniają ustrukturyzowane podejście do zarządzania incydentami od początku do końca.
- Testy są równie ważne jak dokumentacja. Ćwiczenia symulacyjne i symulacje pozwalają wykryć luki w komunikacji, narzędziach, procesie podejmowania decyzji oraz procedurach eskalacji, zanim ujawni je rzeczywisty atak.
- Wprowadź plan w życie. Określ role, udziel wstępnych uprawnień do podejmowania kluczowych działań, ustal protokoły komunikacyjne oraz upewnij się, że narzędzia bezpieczeństwa i procedury operacyjne są gotowe do użycia w sytuacjach kryzysowych.
- Należy na bieżąco aktualizować plan. Zmiany w systemach, zagrożeniach, przepisach, dostawcach i personelu mogą szybko sprawić, że plan reagowania na incydenty stanie się nieaktualny. Niezbędne są regularne przeglądy oraz aktualizacje po wystąpieniu incydentów.
Cyberatak nie zapowiada się z wyprzedzeniem. Pewnego ranka pojawia się alert, ktoś zgłasza problem, a zanim kierownictwo zostanie o tym poinformowane, szkody już się rozprzestrzeniają. Tym, co odróżnia firmy, które opanowują naruszenie bezpieczeństwa w ciągu kilku godzin, od tych, które miesiącami zmagają się z naprawą skutków, nie jest lepsza technologia. Chodzi o przygotowanie. A konkretnie: o to, czy istniał plan, zanim coś poszło nie tak.
Plan reagowania na incydenty (IRP) to udokumentowana i przetestowana procedura służąca do wykrywania incydentów związanych z bezpieczeństwem, ograniczania ich skutków oraz przywracania normalnego stanu. Brzmi to dość biurokratycznie. W praktyce jednak stanowi różnicę między kontrolowaną reakcją a zorganizowanym chaosem o drugiej w nocy.
Co właściwie uznaje się za incydent
Nie każde ostrzeżenie oznacza incydent. Nieudana próba logowania to tylko szum informacyjny. Odszyfrowanie serwera plików przez oprogramowanie ransomware już nie. To rozróżnienie ma znaczenie, ponieważ decyduje o tym, kto i jak szybko zostanie zaangażowany.
Typowe kategorie, które warto zdefiniować, zanim cokolwiek się wydarzy:
- Naruszenie bezpieczeństwa danych: nieuprawniony dostęp do danych wrażliwych lub podlegających regulacjom
- Zakażenie złośliwym oprogramowaniem: oprogramowanie ransomware, oprogramowanie szpiegujące, programy niszczące dane, trojany
- Ataki typu „odmowa usługi”: ataki powodujące ograniczenie wydajności lub unieruchomienie systemów
- Zagrożenie wewnętrzne: złośliwe lub nieumyślne działania pracowników lub wykonawców
- Naruszenie bezpieczeństwa łańcucha dostaw: ataki przeprowadzane za pośrednictwem oprogramowania dostawców (przykładem z podręcznika jest firma SolarWinds)
- Nieuprawniony dostęp: kradzież danych uwierzytelniających, eskalacja uprawnień, przemieszczanie się w sieci
Wiadomość phishingowa, którą kliknięto, ale która nie spowodowała zainstalowania żadnego złośliwego oprogramowania, różni się od tej, która zainstalowała sygnał nawigacyjny Cobalt Strike. Plan musi uwzględniać obie sytuacje i szybko informować zespół, która z nich ma miejsce.
Dlaczego większość planów w rzeczywistości nie działa
Wiele organizacji dysponuje dokumentem dotyczącym reagowania na incydenty. Znacznie mniej z nich posiada dokument, z którym ktokolwiek się zapoznał. A jeszcze mniej przetestowało go w warunkach zbliżonych do rzeczywistej sytuacji.
Typowe problemy: dokument ma już trzy lata, zawiera dane kontaktowe osób, które odeszły z firmy, zakłada stosowanie narzędzi, które zostały już zastąpione, a nikt z obecnego zespołu reagowania nigdy go nie widział. Okazuje się, że istnieje znacząca różnica między posiadaniem dokumentu określającego zasady a posiadaniem podręcznika operacyjnego. Jeden z nich zadowala audytorów. Drugi jest tym, z czego korzystasz, gdy o 3 nad ranem dochodzi do awarii środowiska produkcyjnego i nikt nie wie, kto jest upoważniony do odłączenia zainfekowanego serwera od sieci.
Sześć etapów i ich praktyczne znaczenie
W ramach standardu NIST SP 800-61 proces reagowania na incydenty podzielono na sześć etapów. Organizacja SANS stosuje podobną logikę, używając jednak innych nazw. Niezależnie od tego, struktura pozostaje ta sama.
Przygotowanie
Wszystko, co poprzedza incydent. To właśnie tutaj odbywa się prawdziwa praca: definiowanie, czym jest incydent, tworzenie i szkolenie zespołu reagowania, wdrażanie infrastruktury rejestrowania zdarzeń i powiadamiania oraz przeprowadzanie ćwiczeń symulacyjnych. Jeden szczegół, który jest nieustannie pomijany: uprzednie zatwierdzanie działań. Podczas trwającego incydentu czekanie na zgodę prawną na odizolowanie serwera kosztuje czas, którego nie masz. Zdecyduj z wyprzedzeniem, co można zrobić natychmiast i kto ma to zrobić, bez konieczności eskalacji.
Identyfikacja
Coś się wydarzyło. Pytanie brzmi: co dokładnie? Ten etap polega na przekształceniu alertów w potwierdzone incydenty, skorelowaniu sygnałów z narzędzi SIEM i EDR, określeniu zakresu zdarzenia oraz ustaleniu osi czasu. Szybkość działania w tym przypadku jest bezpośrednio powiązana z jakością rejestrowania zdarzeń, którą ustalono na etapie przygotowań. Niepotrzebne wpisy w logach oznaczają powolną identyfikację. Powolna identyfikacja oznacza mniejszą liczbę dostępnych opcji.
Ograniczanie rozprzestrzeniania się
Krótkoterminowe ograniczanie skutków jest szybkie i radykalne: izolacja zainfekowanych hostów, blokowanie adresów IP atakujących, dezaktywacja przejętych kont. Długoterminowe ograniczanie skutków jest bardziej precyzyjne: tymczasowe poprawki, rekonfiguracja systemów, wzmożony monitoring określonych zachowań. Jedna z decyzji, która pojawia się nieustannie: czy natychmiast odłączyć się, czy najpierw obserwować atakującego? Odłączenie ogranicza szkody. Monitorowanie ujawnia pełny zakres zdarzenia. Istnieją uzasadnione argumenty przemawiające za obydwoma rozwiązaniami. Taka decyzja powinna zostać omówiona z wyprzedzeniem, a nie podejmowana pod presją.
Wykorzenienie
Całkowicie wyeliminuj zagrożenie. Zainstaluj poprawki w miejscach, które zostały wykorzystane, usuń złośliwe oprogramowanie i mechanizmy zapewniające jego trwałość, zmień dane uwierzytelniające oraz przywróć zainfekowane systemy z czystych obrazów. Pominięcie tego kroku lub jego pośpieszne wykonanie sprawia, że organizacje ponownie padają ofiarą ataku przez ten sam wektor już dwa tygodnie później. Dzieje się to częściej, niż ktokolwiek o tym informuje.
Powrót do zdrowia
Przywróć usługi zgodnie z kolejnością priorytetów. Przed ponownym podłączeniem systemów upewnij się, że są one wolne od złośliwego oprogramowania. Uważnie monitoruj sytuację pod kątem ewentualnych powtarzających się zdarzeń. Dbaj też o wypełnienie obowiązków związanych z powiadamianiem – zgodnie z RODO na powiadomienie organów nadzorczych o naruszeniu ochrony danych osobowych masz 72 godziny. Ten termin nie ulega zawieszeniu tylko dlatego, że proces przywracania ciągłości działania wciąż trwa.
Wnioski
Etap, który większość zespołów pomija, bo są wyczerpani. I właśnie dlatego jest on tak ważny. Analiza po zdarzeniu powinna odbyć się w ciągu dwóch tygodni: co się wydarzyło, co się sprawdziło, a co nie, jakie luki ujawniły się, jakie zmiany zostaną wprowadzone i w jakim terminie. Należy to udokumentować. Zaktualizować plan. Następnie faktycznie wdrożyć zmiany; w przeciwnym razie było to tylko spotkanie.
Narzędzia umożliwiające realizację planu
IRP określa, co należy zrobić. Narzędzia pozwalają zrealizować to szybko, nawet w trudnych warunkach.
- SIEM: Splunk, Microsoft Sentinel, IBM QRadar do korelacji logów na dużą skalę
- EDR: CrowdStrike Falcon, SentinelOne, Microsoft Defender – do wykrywania behawioralnego i izolacji punktów końcowych
- SOAR: Palo Alto XSOAR, Splunk SOAR do automatycznego wykonywania scenariuszy
- Analiza zagrożeń: MISP i Recorded Future jako źródła informacji o taktykach, technikach i procedurach (TTP) atakujących
- Kryminalistyka: Velociraptor, Magnet AXIOM, Volatility – narzędzia do prowadzenia dochodzeń i zabezpieczania dowodów
Narzędzia mają mniejsze znaczenie niż to, czy ludzie potrafią z nich korzystać w stresujących sytuacjach. Instancja Splunk z 400 pulpitami nawigacyjnymi i bez instrukcji postępowania nikomu nie pomoże.
Warto wiedzieć o harmonizacji przepisów
W zależności od branży i regionu IRP nie jest opcjonalny – stanowi wymóg prawny. Kluczowe ramy:
- NIST SP 800-61, wersja 2: standard odniesienia dla instytucji federalnych w USA oraz większości środowisk korporacyjnych
- ISO/IEC 27035: międzynarodowa norma dotycząca zarządzania incydentami
- Artykuł 33 RODO: Obowiązek zgłoszenia naruszenia w ciągu 72 godzin w przypadku danych osobowych z UE
- Dyrektywa NIS2: wymogi dotyczące zgłaszania incydentów przez operatorów usług kluczowych w całej UE
- DORA: Wymogi dotyczące odporności sektora finansowego UE obowiązujące od stycznia 2025 r., zawierające wyraźne nakazy przeprowadzania testów na odporność na zakłócenia
- PCI DSS w wersji 4.0: wymagania dotyczące dokumentacji i corocznych testów w sektorze płatności
Obecnie to właśnie NIS2 i DORA zaskakują organizacje. Oba regulacje znacznie podnoszą poprzeczkę w zakresie dokumentacji, częstotliwości testów i terminów składania sprawozdań.
Dostawcy, których warto wziąć pod uwagę
Niektóre organizacje budują potencjał w zakresie reagowania na incydenty (IR) wyłącznie we własnym zakresie. Większość z nich nie dysponuje jednak odpowiednim personelem ani wystarczającym doświadczeniem, by robić to dobrze, zwłaszcza w zakresie symulacji i testów. Krótka lista:
DXC Technology zajmuje się kompleksowym opracowywaniem programów reagowania na incydenty (IR): projektowaniem planów, ćwiczeniami symulacyjnymi oraz zarządzaniem wykrywaniem i reagowaniem na incydenty. Firma ma szczególnie duże doświadczenie w sektorach podlegających regulacjom (energetyka, opieka zdrowotna, usługi finansowe), w tym w zakresie rozwiązań programowych dla energetyki, gdzie zapewnienie zgodności z przepisami jest uwzględnione w projekcie od samego początku.
Firma Secureworks (Atlanta) oferuje usługi w ramach umowy na obsługę zdarzeń bezpieczeństwa (IR) w połączeniu ze swoją platformą Taegis XDR. Jej jednostka Counter Threat Unit publikuje na bieżąco informacje o zagrożeniach, które są bezpośrednio wykorzystywane do aktualizacji scenariuszy działania — jest to przydatne dla zespołów, które chcą realizować wykrywanie i reagowanie w jednym środowisku.
Firma WithSecure (Helsinki) stosuje podejście konsultacyjne do tworzenia programów reagowania na incydenty (IR), ściśle dostosowane do europejskich wymogów regulacyjnych. Rozwiązanie to lepiej sprawdza się w przypadku organizacji, które po raz pierwszy budują swoje zdolności w zakresie reagowania na incydenty, niż w przypadku tych, które poszukują wyłącznie usługi zarządzanej.
Firma Trustwave (Chicago) łączy usługi zarządzania bezpieczeństwem z doradztwem w zakresie reagowania na incydenty (IR) za pośrednictwem SpiderLabs — wewnętrznego zespołu typu „red team”, który w ciągu ostatniej dekady opracował jedne z najbardziej szczegółowych raportów dotyczących zagrożeń w branży.
Orange Cyberdefense (Francja) zajmuje się jednoczesną koordynacją działań w zakresie reagowania na incydenty (IR) w wielu jurysdykcjach UE. Jest to przydatne dla międzynarodowych korporacji, które muszą równolegle wywiązywać się z obowiązków wynikających z dyrektywy NIS2 i rozporządzenia RODO w różnych krajach.
Błędy, które powtarzają się za każdym razem
Nawet dobrze przygotowane zespoły popełniają typowe błędy. Najczęściej powtarzające się z nich to:
- Brak przetestowania planu: dokument, który nigdy nie został sprawdzony w symulowanych warunkach stresowych, to jedynie domysły
- Brak ustalonych protokołów komunikacyjnych: kto rozmawia z prasą, kto dzwoni do organu regulacyjnego, kto powiadamia klientów
- Zakładając, że kopie zapasowe są poprawne, bez ich sprawdzania
- Pomijając podmioty zewnętrzne: dostawcy usług w chmurze, dostawcy oprogramowania SaaS oraz dostawcy usług zarządzanych (MSP) muszą być włączeni w ten proces, a nie tylko informowani o nim po fakcie
- Traktowanie IR wyłącznie jako funkcji informatycznej: działy prawny, komunikacji, kadr oraz kierownictwo odgrywają istotną rolę w przypadku poważnego incydentu
A największym z nich jest traktowanie planu jako jednorazowego projektu. Zagrożenia się zmieniają. Systemy się zmieniają. Ludzie odchodzą. Plan reagowania na incydenty (IRP), który nie jest aktywnie aktualizowany, staje się nieaktualny, zanim jeszcze będzie potrzebny.
Najczęściej zadawane pytania
Ile czasu zajmuje stworzenie od podstaw działającego systemu IRP?
Opracowanie podstawowego planu zajmuje od czterech do sześciu tygodni. Stworzenie dopracowanego programu obejmującego scenariusze działania, sprawdzone ćwiczenia i integrację narzędzi zajmuje realistycznie od trzech do sześciu miesięcy.
Jak często należy to badać?
Co najmniej raz w roku. DORA oraz większość ram organizacyjnych dla przedsiębiorstw zalecają obecnie przeprowadzanie ćwiczeń symulacyjnych dwa razy w roku, w tym co najmniej raz z pełną symulacją. Po każdym poważnym incydencie lub istotnej zmianie w systemie należy niezwłocznie przeprowadzić przegląd.
Jaka jest różnica między ćwiczeniem typu „tabletop” a ćwiczeniem typu „red team”?
Ćwiczenia teoretyczne opierają się na dyskusji; omawiane są scenariusze, bez angażowania systemów. Ćwiczenia z udziałem zespołu czerwonego aktywnie symulują techniki atakujących w odniesieniu do rzeczywistej infrastruktury. Oba rodzaje ćwiczeń są cenne i pozwalają sprawdzić różne aspekty.
Jakie jest pierwsze działanie po potwierdzeniu zdarzenia?
Należy uruchomić zespół reagowania, udokumentować czas zdarzenia i wstępne wskaźniki oraz rozpocząć wstępnie zatwierdzone działania mające na celu ograniczenie rozprzestrzeniania się zagrożenia. Nie należy dotykać zainfekowanych systemów w celu ich oczyszczenia przed zabezpieczeniem dowodów kryminalistycznych; to właśnie te informacje pozwalają ustalić pełny zakres zaistniałego zdarzenia.
Specjalista ds. treści w PowerDMARC
Milena jest wykwalifikowaną pisarką i twórczynią treści z ponad 7-letnim doświadczeniem w tworzeniu angażujących treści na temat IT, cyberbezpieczeństwa, wirtualnych wydarzeń i nie tylko. Ma udokumentowane doświadczenie w dostarczaniu wysokiej jakości prac dla międzynarodowych magazynów i jest absolwentką prestiżowych instytucji, takich jak New York University Abu Dhabi, UWC China i College of Europe.
Najnowsze posty autorstwa Milena Baghdasaryan (zobacz wszystkie)
- Opracowanie planu reagowania na incydenty od podstaw – 8 września 2026 r.
- Nowy sposób, w jaki hakerzy oszukują finansowe asystenty oparte na sztucznej inteligencji – 7 września 2026 r.
- Najlepsze praktyki w zakresie bezpieczeństwa DNS: kompletna lista kontrolna dotycząca wzmocnienia zabezpieczeń – 7 września 2026 r.
