Plan Reagowania na Incydenty 101: Jak go zbudować, szablony i przykłady

Jak zbudować plan reagowania na incydenty w oparciu o proces reagowania na incydenty SANS, przykłady, które pomogą Ci zacząć, a także spojrzenie na automatyzację reagowania na incydenty.

Potrzebujesz rozwiązania do reagowania na incydenty? Kliknij tutaj, aby zobaczyć demo rozwiązania do reagowania na incydenty.

W tym poście dowiesz się:

Co to jest plan reagowania na incydenty i dlaczego go potrzebujesz?
Cykl reagowania na incydenty
Dlaczego plan reagowania na incydenty jest ważny?
Plan reagowania na incydenty a plan odzyskiwania danych
Sześć kroków reagowania na incydenty
Szablon planu reagowania na incydenty
Przykłady planu reagowania na incydenty
Następna generacja reagowania na incydenty

Co to jest plan reagowania na incydenty i dlaczego jest potrzebny?

Plan reagowania na incydenty to zestaw narzędzi i procedur, które Twój zespół bezpieczeństwa może wykorzystać do identyfikacji, eliminacji i usuwania skutków zagrożeń cybernetycznych. Jest on zaprojektowany tak, aby pomóc Twojemu zespołowi szybko i jednolicie reagować na wszelkiego rodzaju zagrożenia zewnętrzne.

Plany reagowania na incydenty zapewniają, że reakcje są tak skuteczne, jak to tylko możliwe. Plany te są niezbędne, aby zminimalizować szkody spowodowane przez zagrożenia, w tym utratę danych, nadużycie zasobów i utratę zaufania klientów.

Plan reagowania na incydenty stanowi podstawę cyklu reagowania na incydenty:

Figura 1: Elementy cyklu reagowania na incydenty

Plan reagowania na incydenty nie jest kompletny bez zespołu, który może go zrealizować – Computer Security Incident Response Team (CSIRT). Zespół reagowania na incydenty to grupa ludzi – albo pracowników IT z pewnym przeszkoleniem w zakresie bezpieczeństwa, albo pełnoetatowych pracowników ds. bezpieczeństwa w większych organizacjach – którzy zbierają, analizują i działają na podstawie informacji o incydencie.

Są oni punktem centralnym incydentu i są odpowiedzialni za komunikację z innymi interesariuszami w organizacji, a także z podmiotami zewnętrznymi, takimi jak radca prawny, prasa, organy ścigania, poszkodowani klienci itp.

Dlaczego plan reagowania na incydenty jest ważny?

Badanie Ponemon Institute’s 2017 Cost of Cyber Crime Study wykazało, że przeciętna organizacja traci 11,7 miliona dolarów rocznie z powodu szkód spowodowanych cyberatakami. Skuteczny proces reagowania może działać w celu znacznego zmniejszenia tych kosztów.

Plany reagowania na incydenty są również ważne dla ochrony danych. Ochrona zasobów danych w całym procesie reagowania na incydenty obejmuje bezpieczne kopie zapasowe, wykorzystanie dzienników i alarmów bezpieczeństwa do wykrywania złośliwej aktywności, właściwe zarządzanie tożsamością i dostępem w celu uniknięcia zagrożeń ze strony osób trzecich oraz poświęcenie dużej uwagi zarządzaniu poprawkami.

Na koniec, planowanie reagowania na incydenty chroni reputację firmy. IDC stwierdziło, że 80% konsumentów przeniosłoby swoje interesy gdzie indziej, gdyby zostali bezpośrednio dotknięci przez naruszenie bezpieczeństwa danych. Jeśli naruszenie bezpieczeństwa nie zostanie odpowiednio szybko rozwiązane, firma ryzykuje utratę biznesu. Zaufanie inwestorów i udziałowców może drastycznie spaść po nagłośnionym naruszeniu bezpieczeństwa danych.

Plan reagowania na incydenty (IRP) pomaga przygotować się na incydenty bezpieczeństwa, a najlepiej im zapobiegać. Reakcje, które dyktuje IRP, mogą mieć również mniej oczywiste pozytywne skutki dla organizacji, w tym:

Ochrona danych – ochrona danych i systemów są podstawą IRP. Ochronę uzyskuje się poprzez zabezpieczanie kopii zapasowych, zapewnienie odpowiedniego zarządzania tożsamością i dostępem oraz terminowe łatanie luk. Środki te są wspierane przez szybką reakcję na alarmy oraz dokładną analizę logów i danych zdarzeń.
Wzmacnia reputację – skuteczna reakcja na incydenty pokazuje zaangażowanie marki w bezpieczeństwo i prywatność. Ataki skutkujące utratą danych mogą sprawić, że klienci zaczną wątpić w kompetencje organizacji, co może doprowadzić do porzucenia marki. Podobnie, udziałowcy i inwestorzy mogą porzucić firmę, która ucierpiała w wyniku naruszenia. IRP może zapobiec lub zminimalizować te straty.
Redukuje koszty – naruszenia są kosztowne, ze względu na kary regulacyjne, odszkodowania dla klientów lub po prostu koszty dochodzenia i przywracania systemów. Według badania przeprowadzonego w 2019 roku przez IBM, średni koszt naruszenia wynosi prawie 4 miliony dolarów. IRP mogą pomóc zmniejszyć ryzyko naruszenia i ograniczyć szkody wyrządzone przez ataki, ograniczając koszty.

Jaki jest związek między planem reagowania na incydenty a planem odzyskiwania danych po awarii?

Plan reagowania na incydenty powinien być uzupełniony planem odzyskiwania danych po awarii. Ten ostatni określa, w jaki sposób organizacja radzi sobie z katastroficznymi zdarzeniami, takimi jak klęska żywiołowa lub przypadkowa utrata danych. Podczas gdy plan reagowania na incydenty koncentruje się na identyfikacji zdarzenia bezpieczeństwa i doprowadzeniu go do końca, odzyskiwanie po awarii ma na celu przywrócenie systemów do działania, z zastrzeżeniem celu czasu przywracania (RTO).

Kluczowe aspekty planowania reagowania na incydenty

Aby plan reagowania na incydenty był skuteczny, powinien zawierać następujące elementy:

Wsparcie kierownictwa wyższego szczebla – wsparcie kierownictwa pozwoli na rekrutację najbardziej wykwalifikowanych członków do zespołu reagowania na incydenty oraz na stworzenie procesów i przepływów informacji, które pomogą w skutecznym zarządzaniu incydentem.
Konsekwentne testowanie – plan reagowania na incydenty nie jest wiele wart, jeśli jest tylko na papierze, musi zostać poddany testom. Przeprowadzenie zaplanowanych (lub jeszcze lepiej, nieplanowanych) ćwiczeń bezpieczeństwa, które pozwolą prześledzić plan i zidentyfikować słabe punkty, w znacznym stopniu przyczyni się do potwierdzenia, że zespół jest gotowy na prawdziwy incydent.
Równowaga pomiędzy szczegółowością a elastycznością – plan musi zawierać konkretne, możliwe do wykonania kroki, które zespół będzie mógł szybko zrealizować w przypadku wystąpienia incydentu. Jednocześnie, tworzenie sztywnych procesów prowadzi do złożoności i niezdolności do radzenia sobie z nieoczekiwanymi scenariuszami. Stwórz szczegółowy plan, ale pozwól na elastyczność, aby obsłużyć szeroki zakres incydentów. Częste aktualizowanie planu może również pomóc w elastyczności – przeglądanie planu co około sześć miesięcy może pomóc w uwzględnieniu nowych rodzajów problemów bezpieczeństwa i ataków, które mają wpływ na Twoją branżę.
Wyjaśnienie kanałów komunikacji – plan powinien jasno określać, z kim zespół zajmujący się incydentami powinien się komunikować, za pomocą jakich kanałów komunikacji i jakie informacje powinny być przekazywane. Jest to krytyczna i czasami pomijana część procesu reagowania. Na przykład, powinny istnieć jasne wytyczne dotyczące poziomu szczegółowości informacji, które powinny być przekazywane do kierownictwa IT, do kierownictwa wyższego szczebla, do dotkniętych działów, do dotkniętych klientów i do prasy.
Poznaj swoich interesariuszy – kim są kluczowe role w organizacji, które powinny być zainteresowane i zaangażowane w incydent bezpieczeństwa? Mogą one ulec zmianie w zależności od rodzaju incydentu i zasobów organizacyjnych, których on dotyczy. Zainteresowane strony mogą obejmować kierowników działów, kierownictwo wyższego szczebla, partnerów, klientów i dział prawny.
Utrzymaj plan w prostocie – dobrze znana zasada zarządzania „Keep it Simple Stupid” (KISS) powinna być stosowana również do planów reagowania. Skomplikowany plan, nawet jeśli jest bardzo dobrze przemyślany, nie jest prawdopodobne, aby był dokładnie przestrzegany w czasie rzeczywistym. Ogranicz szczegóły, kroki i procedury do absolutnego minimum, aby zapewnić, że zespół będzie w stanie przetworzyć i zastosować je do incydentu, gdy tylko wejdzie w „mgłę wojny”.

6 kroków reagowania na incydenty Instytutu SANS

Według podręcznika SANS Institute’s Incident Handlers Handbook, istnieje sześć kroków, które powinny być podjęte przez zespół reagowania na incydenty, aby skutecznie radzić sobie z incydentami bezpieczeństwa. Twój plan reagowania powinien uwzględniać i zapewniać zorganizowany proces dla każdego z tych kroków.

1. Przygotowanie
Na etapie przygotowania należy dokonać przeglądu i skodyfikować podstawową politykę bezpieczeństwa, która stanowi podstawę planu reagowania na incydenty. Należy przeprowadzić ocenę ryzyka i nadać priorytety kwestiom bezpieczeństwa, określić, które aktywa są najbardziej wrażliwe, a co za tym idzie, na których krytycznych incydentach bezpieczeństwa zespół powinien się skupić. Stwórz plan komunikacji i przygotuj dokumentację, która jasno i zwięźle określa role, obowiązki i procesy.

Planowanie to nie wszystko – musisz także zrekrutować członków CIRT, przeszkolić ich, zapewnić im dostęp do wszystkich istotnych systemów oraz narzędzi i technologii potrzebnych do identyfikacji incydentów i reagowania na nie.

2. Identyfikacja
Zespół powinien być w stanie efektywnie wykrywać odchylenia od normalnego działania w systemach organizacyjnych i identyfikować, czy te odchylenia stanowią rzeczywiste incydenty bezpieczeństwa.

W przypadku wykrycia potencjalnego incydentu, zespół powinien natychmiast zebrać dodatkowe dowody, zdecydować o rodzaju i powadze incydentu oraz udokumentować wszystko, co robi. Dokumentacja powinna odpowiadać na pytania „Kto, Co, Gdzie, Dlaczego i Jak”, aby umożliwić ściganie napastników w sądzie na późniejszym etapie.

3. Zapobieganie
Po zidentyfikowaniu przez zespół incydentu bezpieczeństwa, natychmiastowym celem jest jego opanowanie i zapobieżenie dalszym szkodom. Wiąże się to z:

Krótkoterminowym ograniczeniem – może to być tak proste, jak odizolowanie segmentu sieci, który jest atakowany lub wyłączenie serwerów produkcyjnych, które zostały zhakowane i przekierowują ruch na serwery zapasowe.
Długoterminowe powstrzymywanie – zastosowanie tymczasowych poprawek do dotkniętych systemów, aby umożliwić ich użycie w produkcji, podczas odbudowy czystych systemów, przygotowując je do wprowadzenia ich do sieci w fazie odzyskiwania.

4. Wykorzenienie
Zespół musi zidentyfikować pierwotną przyczynę ataku, usunąć złośliwe oprogramowanie lub zagrożenia i zapobiec podobnym atakom w przyszłości. Na przykład, jeśli punktem wejścia do ataku był słaby mechanizm uwierzytelniania, należy go zastąpić silnym uwierzytelnianiem; jeśli wykorzystano lukę w zabezpieczeniach, należy ją natychmiast załatać.

5. Odzyskiwanie
Zespół ostrożnie przywraca dotknięte systemy produkcyjne do działania, aby mieć pewność, że nie dojdzie do kolejnego incydentu. Ważne decyzje na tym etapie to: od kiedy i kiedy przywrócić operacje, jak przetestować i zweryfikować, czy dotknięte systemy wróciły do normy oraz jak długo monitorować systemy, aby upewnić się, że aktywność wróciła do normy.

6. Wyciągnięte wnioski
Ta faza powinna być przeprowadzona nie później niż dwa tygodnie od zakończenia incydentu, aby zapewnić, że informacje są świeże w pamięci zespołu. Celem tej fazy jest uzupełnienie dokumentacji, która nie mogła być przygotowana podczas procesu reagowania oraz dalsze badanie incydentu w celu określenia jego pełnego zakresu, sposobu jego opanowania i wyeliminowania, działań podjętych w celu odzyskania zaatakowanych systemów, obszarów, w których zespół reagujący był skuteczny oraz obszarów wymagających poprawy.

Szablon planu reagowania na incydenty

Poniżej znajdują się cztery szczegółowe szablony, które można wykorzystać do rozpoczęcia planowania reakcji na incydenty:

Szablon planu reagowania na incydenty firmyTechTarget (14 stron) zawiera zakres, scenariusze planowania i cele odzyskiwania; logiczną sekwencję zdarzeń dla reakcji na incydent oraz role i obowiązki zespołu; procedury powiadamiania, eskalacji i deklaracji; oraz listy kontrolne reakcji na incydenty.
>> Pobierz szablon

Szablon reakcji na incydent firmy Thycotic (19 stron) zawiera role, obowiązki i informacje kontaktowe, klasyfikację zagrożeń, działania, które należy podjąć podczas reakcji na incydent, przepisy branżowe i zależne od położenia geograficznego oraz proces reakcji, a także instrukcje dotyczące dostosowania szablonu do konkretnych potrzeb.
>> Pobierz szablon (wymaga rejestracji)

Plan reagowania na incydenty bezpieczeństwa firmy Sysnet (11 stron) zawiera informacje o sposobie rozpoznawania incydentu, rolach i odpowiedzialności, kontaktach zewnętrznych, wstępnych krokach reakcji oraz instrukcje reagowania na kilka typowych rodzajów incydentów, takich jak złośliwe oprogramowanie i nieautoryzowany dostęp do sieci bezprzewodowej.
>> Pobierz szablon (wymaga rejestracji)

Plan reagowania na incydenty w Kalifornijskim Rządowym Departamencie Technologii (4 strony) zawiera 17-stopniową listę kontrolną dla członków zespołu reagującego na incydent, z odniesieniem do bardziej szczegółowych procedur dla konkretnych typów incydentów (które trzeba będzie stworzyć we własnym zakresie).
>> Pobierz szablon

Przykłady planów reagowania na incydenty

Podczas opracowywania planu reagowania na incydenty cenne jest zapoznanie się z rzeczywistymi przykładami planów stworzonych przez inne organizacje. Niektóre z tych przykładów nie będą miały zastosowania do scenariuszy incydentów w Twojej branży, ale mogą dostarczyć Ci inspiracji.

Poznaj przykłady planów z następujących organizacji:

Carnegie Mellon University – w tym definicje, role i obowiązki, metodologia, fazy reakcji na incydent, wytyczne dotyczące zagrożeń wewnętrznych i interakcji z organami ścigania oraz dokumentacja.
Tulane University – w tym zakres, role i obowiązki, definicje incydentów, poziomy eskalacji i etapy reakcji na każdy poziom krytyczności.
Write State University – w tym zakres, etapy reakcji, wykorzystanie narzędzi bezpieczeństwa i lista kontrolna włamań.

The Next Generation of Incident Response: Security Orchestration and Automation (SOAR)

Nie da się zastąpić opracowania planu reagowania na incydenty i wyznaczenia dedykowanych osób, które będą za niego odpowiedzialne. Jednakże, aby zwiększyć skuteczność reagowania na incydenty i umożliwić obsługę większej ilości zdarzeń bezpieczeństwa, powstała nowa kategoria narzędzi, które pomagają zautomatyzować reagowanie na incydenty bezpieczeństwa.

Narzędzia SOAR (Security Orchestration and Automation) mogą:

Integrować się z innymi narzędziami bezpieczeństwa, orkiestrując je w celu umożliwienia kompleksowej odpowiedzi na atak
Automatyzować wieloetapowe procedury reagowania przy użyciu podręczników bezpieczeństwa
Wspierać zarządzanie przypadkami poprzez rejestrowanie wszystkich informacji związanych z konkretnym incydentem bezpieczeństwa, tworzenie kompletnej osi czasu zdarzeń, oraz pomagając analitykom współpracować i dodawać dane i spostrzeżenia do zdarzenia

Aby zobaczyć przykład zintegrowanego rozwiązania bezpieczeństwa, które obejmuje SOAR, a także funkcje User Entity Behavioral Analytics (UEBA) i Security Information and Event Management (SIEM), zobacz Incident Responder firmy Exabeam.

Chcesz dowiedzieć się więcej o reagowaniu na incydenty?

Trzy elementy reagowania na incydenty: Plan, Zespół i Narzędzia
Kompletny Przewodnik po Organizacji CSIRT: How to Build an Incident Response Team
10 Best Practices for Creating an Effective Computer Security Incident Response Team (CSIRT)
How to Quickly Deploy an Effective Incident Response Policy
Bezpieczeństwo IT: Co powinieneś wiedzieć
Kroki reagowania na incydenty: 6 wskazówek dotyczących reagowania na incydenty bezpieczeństwa
Zwalczaj cyberzagrożenia za pomocą automatyzacji zabezpieczeń
IPS Security: Jak aktywne zabezpieczenia oszczędzają czas i powstrzymują ataki