Co to jest plan reagowania na incydenty i jak go utworzyć

Plan reagowania na incydenty zapewnia, że w przypadku naruszenia bezpieczeństwa, odpowiedni personel i procedury są na miejscu, aby skutecznie poradzić sobie z zagrożeniem. Posiadanie planu reagowania na incydenty zapewnia możliwość przeprowadzenia ustrukturyzowanego dochodzenia w celu zapewnienia ukierunkowanej reakcji na zagrożenie.

Jest piątkowe popołudnie i po ciężkim tygodniu pracy w firmowym dziale pomocy technicznej IT myślami jesteś przy zimnej butelce wina, która chłodzi się w lodówce, stanowiąc idealny dodatek do spokojnego wieczoru spędzonego na oglądaniu Netflixa. Myśl ta zostaje przerwana, gdy dzwoni telefon, prawdopodobnie kolejny pracownik proszący o zresetowanie hasła.

Jednakże panika w głosie rozmówcy szybko staje się oczywista, nie mogą otworzyć żadnego ze swoich plików i pytają, czy wiesz, czym jest płatność bitcoinem? Pewnie nic wielkiego, złośliwe oprogramowanie na jednym laptopie to nie koniec świata. Odwracasz się jednak, aby zobaczyć wiele telefonów dzwoniących w biurze, sytuacja wydaje się teraz nieco poważniejsza niż pojedynczy laptop zainfekowany złośliwym oprogramowaniem. Co gorsza, kolega pochyla się nad Tobą, aby powiedzieć Ci, że serwer zawierający dane klientów również został zainfekowany ransomware.

Ten scenariusz rozgrywał się wiele razy na całym świecie, a to, jak skutecznie zareagujesz na tę sytuację, zależy od odpowiedzi na jedno pytanie: „Czy masz plan reagowania na incydenty?”

Dlaczego potrzebujesz planu reagowania na incydenty

Zwykle ważne jest, aby firma posiadała plan reagowania na incydenty, aby pod presją incydentu można było podjąć właściwe decyzje w celu przywrócenia sytuacji pod kontrolą. Incydent związany z bezpieczeństwem cybernetycznym może być bardzo trudną sytuacją, jeżeli reakcja nie zostanie przeprowadzona w sposób zorganizowany, wówczas potencjalny rezultat może spowodować poważne szkody dla reputacji marki.

Aby skutecznie poradzić sobie z incydentem związanym z bezpieczeństwem cybernetycznym, Twoja firma będzie potrzebowała zespołu, który specjalizuje się w reagowaniu na incydenty. Niektóre organizacje nazywają ten zespół Zespołem Reagowania na Incydenty Bezpieczeństwa Komputerowego (CSIRT) – istnieją również inne wersje tego akronimu, takie jak Zespół Reagowania na Incydenty Bezpieczeństwa (SIRT) lub Zespół Reagowania na Incydenty Komputerowe (CIRT). Misja tego zespołu jest taka sama bez względu na to, jak go nazwiemy – ma on realizować ustalony w firmie plan reagowania na incydenty, gdy pojawi się sygnał nietoperza.

Jeśli pracujesz w obszarze bezpieczeństwa danych, masz do czynienia z incydentami bezpieczeństwa na co dzień. Od czasu do czasu, drobny problem z bezpieczeństwem okazuje się być prawdziwą paniką na żywo. Czy kiedy zapali się bat-sygnał, wszyscy będą wiedzieli co robić? Czy każdy członek CSIRT będzie znał swoją rolę i obowiązki oraz czy będzie postępował zgodnie z przyjętym planem?

Gdy stawka jest wysoka, a presja wzrasta, CSIRT będzie działał tak, jak to przećwiczył. Jeśli nie ma planu, nie ma gwarancji, że będzie w stanie właściwie zareagować na incydent cyberbezpieczeństwa.

Jednakże, samo posiadanie planu IR nie wystarczy: zespół CSIRT musi posiadać umiejętności i doświadczenie, aby poradzić sobie z potencjalnie wysoce stresującą sytuacją, taką jak ta. Eksperci ds. informatyki śledczej, analitycy złośliwego oprogramowania, kierownicy ds. incydentów i analitycy SOC będą mocno zaangażowani w działania i będą w terenie, zajmując się sytuacją. Będzie to oznaczało podejmowanie kluczowych decyzji, prowadzenie dogłębnego dochodzenia, przekazywanie informacji zwrotnych kluczowym interesariuszom, a w końcu zapewnianie kierownictwa wyższego szczebla, że sytuacja jest pod kontrolą.

Na dodatek do tego wszystkiego często dochodzi brak czasu. Przepisy dotyczące zgłaszania naruszeń bezpieczeństwa danych stają się coraz bardziej powszechne: na przykład GDPR wymaga, aby firmy zgłaszały incydenty związane z bezpieczeństwem danych w ciągu 72 godzin od ich wykrycia.

Moje doświadczenie w pracy nad incydentami związanymi z bezpieczeństwem cybernetycznym pokazało mi wartość posiadania planu reagowania na incydenty. Zdarzało się, że wzywano mnie do incydentu we wczesnych godzinach porannych, aby stwierdzić, że doszło do naruszenia bezpieczeństwa cybernetycznego, a dyrektor generalny szukał w CSIRT odpowiedzi i wskazówek, jak można zapobiec katastrofie. Plan reagowania na incydenty oznacza, że odpowiedni ludzie, z odpowiednimi umiejętnościami i doświadczeniem, będą na to wezwanie, każdy z nich wie, czego się od nich oczekuje i jakich procedur należy przestrzegać, aby skutecznie opanować i zlikwidować zagrożenie. Posiadanie takiej struktury zawsze okazywało się nieocenione.

Rozważania dotyczące planowania reagowania na incydenty

Plan reagowania na incydenty będzie składał się z kluczowych kryteriów, które mogą być rozwijane w miarę dojrzewania postawy bezpieczeństwa firmy. Istnieje kilka czynników, które należy wziąć pod uwagę podczas tworzenia planu reagowania na incydenty.

Poparcie ze strony kierownictwa wyższego szczebla jest najważniejsze. Tworzenie planu reagowania na incydenty nie powinno być ćwiczeniem polegającym na wypełnianiu pól. Jeśli nie jest on wspierany przez kierownictwo wyższego szczebla, istnieje ryzyko, że zostanie odłożony do czasu, gdy będzie potrzebny. Wyższe kierownictwo powinno określić, co jest wymagane z punktu widzenia procesu i ludzi oraz zapewnić, że wszelkie wymagane wsparcie jest zapewnione.

Zdefiniuj kluczowych interesariuszy. Należy udokumentować dane kontaktowe kluczowych osób i zespołów w godzinach pracy i poza nimi.

Komunikowanie się w jasny sposób. Należy ustalić odpowiedzialność za wysyłanie komunikatów, przydzielanie zadań i odpowiednie działania. Należy również rozważyć, kto powinien być uwzględniony w komunikatach dotyczących incydentów i jak dużo szczegółów jest wymaganych w zależności od odbiorców. Zadania przydzielone zespołom bezpieczeństwa muszą być precyzyjne i techniczne, natomiast aktualizacje dla zarządu muszą być jasne i pozbawione żargonu technicznego.

Zdefiniuj, co stanowi incydent. Określ, które zdarzenia mogą być traktowane jako zwykła działalność biznesowa, a które wymagają wezwania do zgłoszenia incydentu.

• KLUCZOWA WSKAZÓWKA: Matryca triage zapewni zrozumienie powagi incydentu, co pozwoli na szybkie i prawidłowe określenie priorytetów.

Plany i procedury są ważne. Jednak to CSIRT będzie realizował plan reagowania na incydenty i zajmował się ich usuwaniem. Właściwi ludzie i zestawy umiejętności muszą być na miejscu, aby IRP mógł zostać pomyślnie zrealizowany.

CSIRT będzie składał się z różnych zespołów, a każda rola jest kluczem do przekształcenia incydentu z potencjalnej katastrofy w sukces. CSIRT to mieszanka doświadczonego, technicznego i nietechnicznego personelu, który pracuje razem, aby zrozumieć zakres incydentu, jak można go złagodzić i ostatecznie naprawić. Odpowiedni ludzie muszą być zatrudnieni i wprowadzeni na swoje miejsce.

Automatyzacja jest również kluczem do planowania reakcji na incydenty, zrozumienie, jakie narzędzia bezpieczeństwa są na miejscu wraz z ich możliwościami i zasięgiem oznacza, że pewien poziom automatyzacji będzie możliwy. Precyzyjnie dostrojone kontrole bezpieczeństwa zapewniają, że pierwsza linia obrony, Security Operations Center (SOC), reaguje na sensowne i uzasadnione alarmy. Posiadanie wiarygodnych i precyzyjnie dostrojonych alertów oznacza, że niektóre obszary procesu reagowania na incydenty mogą być inicjowane automatycznie i że może być możliwe automatyczne generowanie wstępnego triage’u i zbieranie dowodów dla incydentu. Jeśli automatyzacja generuje dużą liczbę fałszywych alarmów, nie tylko powoduje to zmęczenie w kluczowym obszarze IRP, ale również zwiększa prawdopodobieństwo przeoczenia kluczowego alarmu, jeśli zgubi się on w szumie fałszywych alarmów.

Oprócz planu reagowania na incydenty, firma musi również rozważyć posiadanie planu odzyskiwania danych po awarii. Podczas gdy IRP ma za zadanie zlikwidować zagrożenie związane z incydentem, DRP ma za zadanie przywrócić funkcjonalność firmy i przywrócić ją do działania po poważnej katastrofie naturalnej lub spowodowanej przez człowieka. Jeśli firma nie może funkcjonować, DRP nakreśli kroki wymagane do przywrócenia firmy do działania.

Firma może również potrzebować rozważyć, czy ma na nią wpływ Payment Card Industry Data Security Standard (PCI DSS). Ma to zastosowanie, jeśli firma przetwarza, przechowuje lub przesyła dane dotyczące kart kredytowych klientów.

Kto jest odpowiedzialny w ramach planu reagowania na incydenty

CSIRT składa się z wyspecjalizowanych zespołów, z których każdy ma ważną rolę do odegrania podczas radzenia sobie z incydentem.

Centra Operacji Bezpieczeństwa (SOC) są pierwszą linią obrony. Są to żołnierze na miejscu, którzy działają 24 godziny na dobę, 7 dni w tygodniu. Ich rolą jest przeanalizowanie każdego alarmu bezpieczeństwa, zebranie dowodów i określenie odpowiednich działań. Pracując w systemie zmianowym, Analitycy SOC muszą mieć szerokie zrozumienie zagrożeń cyberbezpieczeństwa, będą mieli dostęp do różnych platform bezpieczeństwa i narzędzi, takich jak SIEM (Security Incident Event Manager) i EDR (Endpoint Detection & Response) rozwiązań. Narzędzia te mogą generować szeroki zakres alarmów, które mogą się różnić od ataków DDoS do złośliwych komend uruchamianych na urządzeniu, analitycy SOC muszą być w stanie zrozumieć i zinterpretować te dane. Jeśli incydent zostanie uznany za wysoce priorytetowy lub wykracza poza zestaw umiejętności SOC, punktem eskalacji jest zespół zarządzania incydentami.

Rola menedżera ds. incydentów została opisana przez mojego kolegę jako „sztuka zaganiania kotów”. Ich zadaniem jest objęcie incydentu, zebranie kluczowych interesariuszy i poprowadzenie dyskusji w celu ustalenia najlepszego planu działania. Zespół zarządzający incydentem to generałowie, otrzymują dowody, rady i opinie oraz nadają tempo incydentowi. Określają, jakie zadania muszą zostać wykonane, kto musi je wykonać oraz do kiedy powinny zostać wykonane. Wszelkie rozmowy i komunikaty dotyczące incydentów, które muszą być zaplanowane, są wykonywane przez Zarządzanie Incydentami.

Zespół CIRT to żołnierze Special Ops, są oni zaangażowani tylko w incydenty o wysokim profilu i priorytecie, a kiedy nie są zaangażowani w incydenty, doskonalą i rozwijają swoje umiejętności. Podczas gdy analitycy SOC będą mieli szeroki zestaw umiejętności, zespół CIRT będzie składał się z osób o wyspecjalizowanych umiejętnościach i zainteresowaniach, takich jak analitycy złośliwego oprogramowania i eksperci od cyfrowej kryminalistyki. Zespół ten zapewnia fachowe doradztwo techniczne i analizy oraz otrzymuje od Incident Management zadania, które nie mogą być realizowane przez SOC.

Zespół Threat Intelligence to zwiadowcy, którzy oceniają i rozumieją krajobraz cyberzagrożeń. Jeśli incydent dotyczy skompromitowanego serwera zawierającego poufne dane, będą oni przeszukiwać ciemną sieć w poszukiwaniu dowodów na to, że dane te są na sprzedaż. Jeśli incydent dotyczy infekcji złośliwym oprogramowaniem, zespół wywiadowczy przeprowadzi badania OSINT (Opensource Intelligence) na temat rodziny złośliwego oprogramowania i doradzi, czy jest to atak ukierunkowany na Twoją organizację.

6 kroków do stworzenia planu reagowania na incydenty

SANS opublikował kilka lat temu podręcznik obsługi incydentów, który pozostaje standardem dla planów reagowania na incydenty. Jest to 6 kroków, które możesz wykorzystać do zbudowania planu dla swojej firmy.

Przygotowanie

Przygotowanie do każdego potencjalnego incydentu bezpieczeństwa jest kluczem do udanej reakcji. Zalecam opracowanie podręczników postępowania, które dostarczą wskazówek dla SOC podczas rozwiązywania incydentów. Dadzą one jasne instrukcje, jak nadać priorytet incydentom i kiedy należy je eskalować. Powinny one być wysokopoziomowe i skupiać się na konkretnych obszarach, takich jak DDoS, malware, Insider Threat, nieautoryzowany dostęp i Phishing. Podręczniki i procedury powinny być przetestowane na osobach i zespołach, które będą z nich korzystać. Ćwiczenia na stołach są doskonałym sposobem na ugruntowanie wiedzy i sprawdzenie, czy można wprowadzić jakieś ulepszenia.

Identyfikacja

Możesz skutecznie usunąć zagrożenie bezpieczeństwa tylko wtedy, gdy znasz rozmiar i zakres incydentu. Zacznij od „pacjenta zero”, czyli początkowego zagrożonego urządzenia. Celem jest zrozumienie pierwotnej przyczyny kompromitacji, jednak nie należy koncentrować się tylko na jednym urządzeniu – czy zagrożenie mogło się rozprzestrzenić i przemieścić na boki?

Prawdziwa identyfikacja incydentu polega na zebraniu użytecznych wskaźników kompromitacji (IOC). Zamiast tylko odbudowywać pierwotnie zainfekowane urządzenie, należy zidentyfikować wszelkie unikalne IOC, które mogą być wykorzystane do przeszukania całej nieruchomości w poszukiwaniu dalszych dowodów kompromitacji. Jeśli incydent związany jest z infekcją złośliwym oprogramowaniem, należy zadać następujące pytania: jakie połączenia sieciowe generuje złośliwe oprogramowanie? Czy złośliwe oprogramowanie łączy się z jakimiś domenami? Jakie pliki są tworzone na dysku? Jakie procesy są uruchamiane? Czy są jakieś unikalne klucze rejestru, które zostały utworzone? Te dane mogą być wykorzystane do poszukiwania dalszych dowodów kompromitacji i identyfikacji innych zainfekowanych maszyn w posiadłości.

Zabezpieczanie

Po pomyślnym zidentyfikowaniu zakresu incydentu można rozpocząć proces zabezpieczania. Polega on na odizolowaniu zainfekowanych urządzeń od reszty sieci w celu powstrzymania rozprzestrzeniania się ataku.

Krótkoterminowe powstrzymywanie może być stosowane w celu odizolowania urządzenia, które jest celem ataku. Długoterminowe powstrzymywanie może być konieczne, gdy wymagana jest dogłębna analiza, która może być czasochłonna. Może to obejmować wykonanie obrazu urządzenia i przeprowadzenie analizy kryminalistycznej dysku twardego. Może to wygenerować kolejne IOC, a faza identyfikacji może wymagać ponownego przeanalizowania.

Ekstrakcja

Po pomyślnym opanowaniu incydentu można przystąpić do eliminacji zagrożenia. Będzie się to różnić w zależności od tego, co spowodowało, że urządzenie zostało skompromitowane. Łatanie urządzeń, rozbrajanie złośliwego oprogramowania, wyłączanie skompromitowanych kont to przykłady tego, co może być wymagane w fazie eliminacji incydentu.

Odzyskiwanie

Celem fazy odzyskiwania incydentu jest przywrócenie normalnego działania firmy. Jeśli dostępne są czyste kopie zapasowe, można je wykorzystać do przywrócenia usług. Alternatywnie, każde zagrożone urządzenie będzie wymagało odbudowy w celu zapewnienia czystego przywrócenia. Konieczne może być wdrożenie dodatkowego monitorowania zagrożonych urządzeń.

Wyciągnięte wnioski

Po całkowitym usunięciu zagrożenia następnym krokiem będzie odpowiedź na pytanie „jak zapobiec powtórzeniu się takiej sytuacji?”. Powinno odbyć się spotkanie znane jako Post Incident Review (PIR), w którym powinni wziąć udział przedstawiciele wszystkich zespołów zaangażowanych w incydent. Jest to platforma do dyskusji na temat tego, co poszło dobrze podczas incydentu i co można poprawić. W tym miejscu plan reakcji na incydent jest udoskonalany w oparciu o wyniki PIR, a procedury i podręczniki odtwarzania są zmieniane w celu odzwierciedlenia wszelkich uzgodnionych zmian.

Najlepsze praktyki w zakresie planu reakcji na incydent

Stwórz podręczniki odtwarzania. Stworzenie podręczników postępowania pozwoli SOC dowiedzieć się, jak traktować różne incydenty i zebrać odpowiednie dowody. Skoncentruj się na głównych scenariuszach ataków, z którymi stykają się firmy – złośliwym oprogramowaniu, DDoS, nieautoryzowanym dostępie, phishingu i zagrożeniach wewnętrznych. Dokumenty te powinny określać, co powoduje eskalację do zespołu zarządzania incydentami i doradzać, jakie dowody należy zebrać. Utrzymuj je na wysokim poziomie, nie powinny być zbyt szczegółowe, aby nie stały się zbyt skomplikowane.

Przeprowadź ćwiczenia w zakresie zagrożeń cybernetycznych. Przygotuj się na rzeczywistość, rozgrywając scenariusze ataków, może to być nawet tak proste, jak zorganizowanie ćwiczeń na stole. Stworzenie scenariuszy ataków, które mogą być omawiane przez odpowiednie zespoły, jest doskonałym sposobem na przetestowanie wszelkich podręczników, które zostały wprowadzone, pomoże to również zidentyfikować wszelkie luki w planie reagowania na incydenty i powinno być przeglądane co najmniej raz w roku.

Rozpocznij polowanie na zagrożenia. Czekanie na alarm na nowej, błyszczącej platformie to jedno, ale proaktywne poszukiwanie podejrzanej aktywności to moment, w którym zespoły reagowania na incydenty zaczynają dojrzewać. Nie tylko potencjalny kompromis może zostać znaleziony wcześniej, ale również osoby, które przeprowadzają te doraźne dochodzenia, rozwijają swoje umiejętności śledcze. Te umiejętności i ten typ sposobu myślenia są dokładnie tym, co jest wymagane w fazie identyfikacji incydentu, odpytywania ruchu sieciowego, przyglądania się nietypowo używanym portom i nietypowym procesom, aby zrozumieć rozmiar incydentu. Jeśli SOC ma silne zrozumienie tego, jak wygląda „normalność”, dużo łatwiej jest wykryć złośliwą aktywność.

Szablony planów reagowania na incydenty

Stworzenie planu reagowania na incydenty może wydawać się dość zniechęcające. Jednak użycie szablonu zapewni strukturę i kierunek, w jaki sposób opracować skuteczny plan reagowania na incydenty.

Przewodnik planowania NCSC – NCSC (National Cyber Security Centre) jest brytyjską organizacją rządową, która zapewnia wsparcie w zakresie cyberbezpieczeństwa dla krytycznych organizacji brytyjskich. Jako główny autorytet w dziedzinie cyberbezpieczeństwa, ich zalecenia okażą się nieocenione przy planowaniu planu reagowania na incydenty.

Sysnet’s Incident Response Template – Przedstawia sposób rozpoznawania incydentu bezpieczeństwa, role i obowiązki kluczowych interesariuszy, etapy planu reagowania na incydenty oraz co należy wziąć pod uwagę w przypadku różnych typów incydentów.

Incidentresponse.com udostępnia kilka szablonów playbooków, które obejmują scenariusze takie jak złośliwe oprogramowanie, phishing, nieautoryzowany dostęp, a wszystkie są odwzorowane w NIST incident response framework. Będą to oddzielne, samodzielne dokumenty, ale powinny być uwzględnione w planie reagowania na incydenty.

Aby pomóc zrozumieć, kiedy plan reagowania na incydenty powinien być używany, webinarium Varonis poświęcone reagowaniu na incydenty przedstawia symulację ataku na żywo. Podczas tej symulacji nasi analitycy bezpieczeństwa przedstawiają krótką wycieczkę po Varonis dla Office 365, przeprowadzają atak od włamania, przez eskalację uprawnień, po eksfiltrację, a następnie pokazują, jak używać DatAlert do wykrywania i reagowania.

Co zrobić po incydencie cybernetycznym?

Pył opadł, źli ludzie zostali pokonani, a zespół CSIRT postępował zgodnie z planem IR. Co dalej? Dokonaj podsumowania i uzupełnij zapasy na następne spotkanie.

Zaostrz plan IR lub poszukaj możliwości poprawy już istniejącego monitoringu, czy są jakieś dodatkowe logi, które nie były dostępne podczas incydentu, a wymagają umożliwienia? Czy istnieje luka w umiejętnościach w zespole bezpieczeństwa? Czy polityka firmy dotycząca łatania wymaga przeglądu? Ciągły przegląd i udoskonalanie procesu reagowania na incydenty zapewnia, że nie tylko reakcja na incydent zostanie usprawniona, ale również zmniejszy się powierzchnia ataku. Jeżeli w firmie wprowadzane są dodatkowe kontrole i ulepszenia w zakresie bezpieczeństwa, to w ostatecznym rozrachunku będzie to skutkowało mniejszą liczbą incydentów bezpieczeństwa.