Incydent bezpieczeństwa – wprowadzenie do obsługi

W artykule „Jak nie reagować na atak hackerski” opisałem 10 często popełnianych błędów w reakcji na incydent bezpieczeństwa. Skoro już wiemy jak nie reagować warto byłoby się też zapoznać z dobrymi praktykami w tym temacie. Ponieważ temat jest dość złożony zajmować się nim będziemy w cyklu artykułów poświęconych obsłudze incydentów bezpieczeństwa. W tym tekście zajmiemy się krótkim wprowadzeniem do tematu i przybliżeniem podstawowych pojęć związanych z incydentami bezpieczeństwa, reagowaniem na nie i procesem obsługi incydentu. 

Czym jest incydent bezpieczeństwa?

Zacznijmy od podstaw. Aby prawidłowo rozpocząć procedurę reakcji na incydent bezpieczeństwa należy najpierw ustanowić definicję, którą będziemy się posługiwali w celu stwierdzenia czy dane zdarzenie rzeczywiście stanowi incydent. Posłużyć się tutaj możemy definicją ogólną: incydent bezpieczeństwa możemy zdefiniować jako każde bezprawne, nieautoryzowane lub nieakceptowalne działanie w systemie komputerowym lub innym urządzeniu elektronicznym (np. telefonie), którego efektem jest naruszenie poufności, integralności lub dostępności systemu lub danych.
Ponadto w celu ustalenia czy incydent wiąże się również z naruszeniem prawa można się posłużyć definicją przestępstwa komputerowego zawartą m.in. w art. 267, 268, 268a, 269, 269a oraz 269b Kodeksu Karnego.

Informacje o ewentualnym naruszeniu prawa mogą pomóc na późniejszym etapie dochodzenia podjąć decyzję, w którym kierunku prowadzone będą działania. Może się bowiem zdarzyć, że środki poświęcone na ustalenie sprawcy incydentu okażą się zmarnowane, gdyż będzie się on w stanie skutecznie bronić przed zarzutami. Wówczas lepiej skupić się na naprawie szkód i wdrożeniu zabezpieczeń.

Uwaga:
W sytuacji, gdy nie mamy pewności, co do tego, czy zdarzenie stanowi incydent bezpieczeństwa, każdą podejrzaną nawet aktywność zawsze należy traktować jako potencjalny incydent, który trzeba zbadać i ewentualnie udowodnić, że nim nie jest. Do przykładowych incydentów bezpieczeństwa komputerowego zaliczyć możemy:

• kradzież danych, takich jak dane osobowe, wiadomości e-mail i dokumenty
• kradzież funduszy, np. nieuprawniony dostęp do konta bankowego, skorzystanie z karty kredytowej lub oszustwo dotyczące przelewów
• wyłudzenie informacji
• nieuprawniony dostęp do zasobów komputerowych
• obecność szkodliwego oprogramowania, np. narzędzi zdalnego dostępu i programów szpiegujących
• posiadanie nielegalnych lub nieautoryzowanych narzędzi lub danych.

Reakcja na incydent bezpieczeństwa (IR)

Reakcja na incydent (z ang. Incident Response – IR) to skoordynowana akcja przeprowadzana od chwili wykrycia incydentu do rozwiązania zaistniałego problemu. Głównym celem reagowania na incydent bezpieczeństwa jest pozbycie się zagrożenia ze środowiska komputerowego organizacji, zminimalizowanie szkód oraz przywrócenie normalnej działalności. Do działań przeprowadzanych w ramach reakcji na incydent zaliczamy m.in.:

• Ustalenie, czy rzeczywiście doszło do incydentu oraz czy incydent w dalszym ciągu trwa
• Ustalenie początkowej metody przeprowadzenia ataku.
• Ustalenie użytych szkodliwych programów i narzędzi.
• Ustalenie, które systemy zostały zainfekowane i w jaki sposób się to stało.
• Ustalenie, czego intruzom udało się dokonać (szacowanie szkód).
• Szybkie wykrycie systemów dotkniętych incydentem i ograniczenie szkód.
• Ustalenie i zabezpieczenie prawdziwych informacji.
• Minimalizowanie negatywnego wpływu na działalność organizacji i działanie sieci.
• Przywrócenie normalnego toku pracy.
• Odpowiednie podanie informacji do wiadomości publicznej.
• Przedsięwzięcie prawnych lub cywilnych kroków przeciwko sprawcom.
• Wzmocnienie zabezpieczeń w celu obrony przed kolejnymi incydentami.

Zespół

Na czas trwania procesu reakcji na incydent powołany powinien zostać zespół osób, których zadaniem jest przeprowadzenie dochodzenia i zneutralizowanie negatywnych skutków incydentu. Skład tego zespołu powinien uwzględniać potrzeby szybkiego dostępu do danych i systemów z uprawnieniami administracyjnymi oraz dostępu do miejsc i pomieszczeń, w których zlokalizowane są systemy informatyczne. W skład zespołu powinna też wchodzić osoba, która będzie odpowiedzialna za komunikację z resztą organizacji, w tym z osobami decyzyjnymi na wyższych szczeblach struktury organizacyjnej. Bardzo istotne jest, aby osoby zaangażowane w bezpośrednie prowadzenie czynności naprawczych i dochodzeniowych mogły się skupić na swojej pracy i nie były rozpraszane przez innych pracowników. Komunikację na zewnątrz powinna w związku z tym prowadzić jedna, wyznaczona osoba. W przypadku incydentu o charakterze mogącym mieć negatywne skutki również na zewnątrz organizacji (np. dla klientów lub kontrahentów) konieczne może być zaangażowanie rzecznika prasowego lub pracownika działu PR. Przydatne w trakcie obsługi incydentu mogą się również okazać konsultacje prawne.

Czynności wstępne

Celem tego etapu procesu obsługi incydentu jest zebranie zespołu IR oraz zgromadzenie i przejrzenie szybko dostępnych danych w celu ustalenia rodzaju incydentu oraz oceny potencjalnych jego skutków. Na tym etapie zazwyczaj nie zbiera się jeszcze szczegółowych danych do analizy bezpośrednio z dotkniętego systemu, a raczej z sieci, dzienników systemowych oraz innych źródeł kontekstowych. Na ich podstawie można podjąć decyzję, jakie środki zaradcze należy przedsięwziąć. Podejmowane działania mogą się różnić w zależności poziomu krytyczności systemu lub danych dotkniętych incydentem. Do prac wykonywanych na tym etapie należą m.in.:

• Przeprowadzenie rozmów z osobami, które zgłosiły incydent, w celu wydobycia jak największej ilości przydatnych informacji.
• Przeprowadzenie rozmów z pracownikami technicznymi (programiści, administratorzy), którzy mogą coś wiedzieć o szczegółach incydentu.
• Przeprowadzenie rozmów z pracownikami biznesowymi, którzy mogą coś wiedzieć na temat zdarzeń biznesowych mogących mieć związek z incydentem.
• Przejrzenie dzienników sieci i systemów bezpieczeństwa w celu znalezienia informacji pozwalających na potwierdzenie, że incydent miał miejsce.
• Udokumentowanie informacji zebranych ze wszystkich źródeł.

Śledztwo

Celem śledztwa jest ustalenie faktów dotyczących tego, co się stało, jak do tego doszło oraz w niektórych przypadkach kto jest za to odpowiedzialny (chociaż nie zawsze będzie to możliwe). Bez informacji na temat tego w jaki sposób intruz w ogóle uzyskał dostęp do sieci albo co zrobił, szanse na skuteczne pozbycie się problemu są niewielkie. Często błędnym działaniem okazuje się pochopne odłączenie od prądu i odbudowa zainfekowanego systemu od zera, gdyż wiąże się to z ryzykiem ponownego wystąpienia incydentu. Dlatego tak istotne jest dokładne ustalenie w jaki sposób do niego doszło. Jest to oczywiście ryzykowne, ponieważ prowadząc dochodzenie dajemy intruzowi możliwość dalszego szkodzenia w systemie. O ile takie podejście jest w większości przypadków lepsze, to każdy przypadek należy jednak traktować indywidualnie i świadomie podejmować decyzje.

Wiemy już jak powinien wyglądać ogólny proces obsługi incydentu bezpieczeństwa. W kolejnym artykule zajmiemy się jego szczegółowym przebiegiem i omówimy poszczególne etapy śledztwa. Jeśli chcesz być poinformowany o publikacji kolejnej części cyklu, zapisz się do naszego newslettera poniżej. I tradycyjnie prosimy o udostępnienie tego artykułu.

Obserwuj

Obserwuj