Jak reagować na zagrożenie

Prędzej czy później niemal każda organizacja napotka incydent – rozumiany jako atak hakerski, ransomware czy innego rodzaju złośliwe oprogramowanie, a od sposobu reakcji na takie zdarzenie zależeć będzie skala szkód, jakie ów incydent wyrządzi. Dobrze przygotowana procedura reagowania na incydent pozwoli zminimalizować szkody i umożliwi sprawną realizację obowiązków określonych przepisami prawa.

Moment, w którym kierownictwo organizacji uświadamia sobie, że ma do czynienia z incydentem z zakresu cyberbezpieczeństwa, jest kluczowy dla całej obsługi takiego zdarzenia, gdyż już od tej chwili powinny zostać wdrożone pierwsze kroki związane z ograniczeniem skutków zaistniałej sytuacji (np. odcięciem dostępów) i jej wyjaśnieniu. Najlepszym sposobem na uniknięcie nerwowych działań jest opisanie krok po kroku czynności, jakie mają zostać podjęte w związku z incydentem. Dobra procedura reagowania na incydent jako dokument, nie jest dziełem jednej osoby, ale tworzona jest wspólnie z osobami, które w razie konieczności taką procedurę będą wdrażały.

Przedstawiamy kroki, jakie należy podjąć w celu zbudowania dobrej procedury reagowania na incydent („Procedura”).

Krok pierwszy: Planowanie

Dobra procedura reagowania na incydent nie powstaje w zaciszu gabinetu doradcy prawnego, szefa IT czy lidera działu compliance. Dobra procedura reagowania na incydent to dokument, który jest dziełem wspólnym osób zainteresowanych, które będą miały za zadanie zrealizować tę procedurę.

W ramach planowania konieczne jest zbadanie regulacji, jakim podlega lub może podlegać organizacja w obliczu incydentu. Niezbędne jest zatem uwzględnienie przepisów RODO, które musimy brać pod uwagę zawsze wtedy, gdy incydent dotyczy lub może dotyczyć danych osobowych. Jeśli organizacja jest tzw. Dostawcą Usługi Kluczowej to konieczne jest także zapewnienie zgodności z ustawą o krajowym systemie cyberbezpieczeństwa. Dodatkowo, w przypadku większych organizacji konieczne może być też uwzględnienie wymogów „centrali”, np. zagranicznej spółki dominującej.

Krok drugi: Wykrywanie

Ta część procedury adresowana jest do wszystkich pracowników organizacji i polega na zakomunikowaniu pracownikom, że należy zgłosić wszystkie podejrzane działania/zachowania na zasobach, które zostały im powierzone. Konieczne jest także określenie sposobów monitoringu zasobów oraz sieci, gdyż ludzkie oko nie wszystko jest w stanie zauważyć i dobry monitoring (np. SIEM, DLP, IPS czy IDS) znacznie ułatwi nam zadanie w zakresie wykrywania incydentów.

Należy też pamiętać, że informacja o incydencie może pochodzić z innych źródeł, np. z anonimowego zgłoszenia, mediów czy bezpośrednio od atakującego. Ważne, aby każdy kto uzyskuje taką informację, wiedział, do kogo ją przekazać.

Krok trzeci: Zespół ds. reagowania

Niektóre organizacje posiadają stałych specjalistów albo nawet całe zespoły, które są w stanie kompleksowo zareagować na incydent. Z naszego doświadczenia wynika jednak, że bardzo dobrym sposobem radzenia sobie z incydentami jest powoływanie ad hoc zespołu ds. reagowania na incydent. Liczebność i skład zespołu powinny być dostosowane do przewidywanej skali incydentu oraz do samej organizacji.

Do członków takiego zespołu powinni zostać włączeni:

1. specjaliści IT, w szczególności z zakresu dotkniętego przez incydent;

2. przedstawiciel działu, w którym doszło do incydentu (jest to szczególnie istotne dla ustalenia informacji i danych, które będą podlegać incydentowi);

3. inspektor ochrony danych lub inna osoba koordynująca kwestię ochrony danych osobowych w organizacji;

4. doradca prawny lub compliance oficer.

Pierwsze spotkanie zespołu powinno polegać na określeniu ram czasowych dla poszczególnych działań. Nasze doświadczenie pokazuje, że podzielenie czasu przewidzianego na obsługę incydentu na mniejsze segmenty i działania oraz powierzenie ich odpowiednim osobom pozwala na należytą obsługę incydentu.

Krok czwarty: Analiza

Najważniejszy krok w ramach procedury to przeprowadzenie przez zespół szybkiej analizy dostępnych informacji w celu określenia:

1. przyczyny incydentu;

2. wektora ataku;

3. skali incydentu;

4. sposobów zatrzymania i usunięcia incydentu.

W tym momencie konieczne jest też zaplanowanie poszczególnych kroków prawnych (np. zgłoszeń do prezesa UODO) i komunikacji kryzysowej.

Krok piąty: Zatrzymanie incydentu

W procedurze konieczne jest przewidzenie sposobów przydzielenia odpowiednich zasobów w celu podjęcia natychmiastowych działań. Zespół najpierw określa, jakie działania muszą być podjęte, przydziela zasoby i następnie zarządza rozpoczęcie działań pozwalających na zatrzymanie incydentu w pierwszej chwili (np. odcięcie przestępcy od zasobów organizacji).

Kolejnym krokiem w ramach zatrzymania incydentu jest usunięcie jego przyczyny – np. złośliwego oprogramowania. Sposób usunięcia przyczyny incydentu jest zależny od jego charakteru i może być określony przez zespół w ramach wykonywanej analizy.

Krok szósty: Przywracanie

W ramach tego kroku zespół podejmie działania w celu przywrócenia normalnych funkcjonalności systemów i aplikacji w organizacji. Rozpoczęcie przywracania jest możliwe tylko wtedy, gdy incydent został już zatrzymany i usunięty. W tej fazie procedury konieczne może być przywrócenie danych z kopii zapasowych, zamiana uszkodzonych części bądź całych zasobów, jeśli zostały skradzione.

Sposób przywracania powinien zostać określony przez zespół i jest zależny od charakteru i skali incydentu. Po przywróceniu funkcjonalności oraz zasobów incydent może zostać zamknięty.

Krok siódmy: Wnioski po incydencie

W ramach prac zespołu powinien powstać raport z incydentu, który poza opisem samego wcześniejszych kroków zawierać będzie rekomendacje dotyczącego sposobu na uniknięcie podobnego incydentu w przyszłości. Z każdego incydentu należy wyciągnąć wnioski na przyszłość i podjąć odpowiednie działania. W tym wypadku również wnioski i działania zależne są od incydentu, ale mogą polegać przykładowo na przeprowadzeniu szkoleń lub zakupie nowych urządzeń lub aplikacji.

Krok ósmy: Testowanie

Wreszcie, dobra procedura reagowania na incydent musi zostać przetestowania „w ogniu” – tylko w ten sposób organizacja może być pewna, że w obliczu kryzysu pracownicy postąpią właściwe i w sposób zgodny z procedurą. Pisząc „w ogniu” nie mam na myśli celowego wywołania incydentu, a jedynie przeprowadzenie testowego sprawdzenia, czy wszyscy adresaci poszczególnych zadań są ich świadomi oraz czy wiedzą, co robić.

Nasze doświadczenia pokazują, że tak zbudowane procedury reagowania na incydent pozwalają na zminimalizowanie skutków incydentu i zachowanie zgodności z prawem. Usystematyzowanie zadań i czynności oraz wyznaczenie terminów na ich wykonanie pozwala na uniknięcie paniki – trzeba jednak pamiętać, że procedura nie może być zbyt „sztywna”, a Zespół musi mieć elastyczność w działaniach, gdyż w dzisiejszym świecie możemy mieć do czynienia z bardzo różnymi i często skomplikowanymi incydentami.