10 lat temu, kiedy zaczynaliśmy informatykę śledczą (digital investigation) w Polsce, była ona głównie narzędziem w rękach dochodzeniowców policyjnych.

Choć z czasem pojawiały się coraz bardziej złożone sprawy, jak na przykład afera paliwowa, oszustwa na VAT byłego posła czy też sprawa Katarzyny W., to w organizacjach śledztwa komputerowe pojawiały się niezwykle rzadko.

Bezpieczeństwo informatyczne w przedsiębiorstwach koncentrowało się na budowaniu odpowiedniego poziomu zabezpieczeń, które w założeniu miały uchronić biznes przed wszelkimi zagrożeniami, nie dopuszczając do występowania incydentów. Było tak, pomimo, że normy dotyczące systemów bezpieczeństwa informacji, jak na przykład ISO27001, wskazywały na konieczność bycia przygotowanym na wystąpienie „problemów”, a w momencie kiedy takowe wystąpią, zastosowanie odpowiednich procesów w celu wyjaśnienia danego incydentu oraz zgromadzenia odpowiednich dowodów (zob. PN/ISO 27001:2005).

Dziś wiemy już, że koncepcja oparta tylko o systemy zabezpieczeń nie sprawdziła się. W ciągu ostatnich lat przekonaliśmy się, że żadne z nich nie jest w stanie zapewnić stuprocentowej ochrony, szczególnie w otoczeniu w którym informacja stała się bardziej cenna niż narkotyki. Przykłady kompromitacji zabezpieczeń można by wymieniać dziesiątkami, a straty z nimi związane są ogromne. I nie mówimy tu tylko o kwestiach finansowych. Dlatego organizacje przygotowane powinny dziś zakładać, że system bezpieczeństwa musi być wzbogacony o sprawnie działający element response, którego niezbędnym składnikiem jest informatyka śledcza. Oznacza to, że rola informatyka śledczego w systemach bezpieczeństwa znacznie wzrosła, a w przyszłości funkcjonowanie tych systemów bez nas stanie się niemożliwe.

Incident response a informatyka śledcza

Przeciętnie zorientowany czytelnik wyczuwa różnicę pomiędzy zdarzeniem, a incydentem bezpieczeństwa. Warto jednak przypomnieć, że w rozumieniu normatywnym, zdarzeniem jest wystąpienie „epizodu”, który ma związek z systemem bezpieczeństwa informacji ale nie musi to być naruszenie poufności, integralności bądź dostępności, czyli incydent bezpieczeństwa. Posłużmy się tu przykładem logu z jednej ze stacji roboczych dostarczanych do naszego SIEM, który wykazał próbę wielokrotnego logowania na konto użytkownika z uprawnieniami administracyjnymi na tej stacji. Sam fakt logowania nie określa jednak czy mamy do czynienia z zagrożeniem. Być może użytkownik zapomniał wyłączyć capslock. Może być jednak tak, że inny pracownik próbuje użyć hasła z kartki przyklejonej pod klawiaturą niefrasobliwego admina, na której ten nie dość czytelnie je zapisał. Żeby ustalić czy mamy do czynienia z incydentem czy zdarzeniem, w dojrzałej organizacji powinien uruchomić się mechanizm, który powinien zdecydować, czy problemem należy zarządzać czy nie. Decyzja o sklasyfikowaniu zdarzenia jako incydentu oznacza przejście w kierunku eskalacji i czynności związanych z reakcją (response).

Formalnie rzecz biorąc oznacza to konieczność podjęcia określonej akcji, zależnej od klasy incydentu. Ważne przy tym jest, że podstawowym celem zarządzania incydentem jest powstrzymanie strat (wycieku danych) a następnie remediacja. W tym przypadku reakcją może być niezwłoczne zablokowanie podejrzanej stacji i telefon do użytkownika z pytaniem „o co chodzi?”. Krótkie wyjaśnienie może zamknąć sprawę. Inaczej jednak będzie jeśli użytkownik, na którego konto wystąpiły próby logowania, akurat jest na L4 i nie korzystał z komputera. W tym momencie konieczne może stać się przeprowadzenie dochodzenia i wykorzystanie informatyki śledczej. Jak wiemy, dla tego procesu, najważniejsze jest zgromadzenie dowodów zdatnych do przedstawienia w sądzie (jeśli zajdzie taka potrzeba) oraz przedstawienie raportu z wykrytych podatności w celu zapobieżenia takim incydentom w przyszłości. Efektem może być na przykład zwolnienie pracownika, który próbował logowania na cudze konto, co wykazał monitoring video, potwierdzony logami z systemu.

Powyższy przykład obrazuje codzienność dzisiejszych systemów bezpieczeństwa. Wśród tysięcy zdarzeń część jest incydentami, a część wymaga przeprowadzenia analiz z wykorzystaniem informatyki śledczej. Przedstawia to poniższy rysunek:

Reakcja na incydent IT

Reakcja na incydent IT

W praktyce im lepiej przygotowany system tym czas pomiędzy zdarzeniem, a reakcją jest krótszy. Informatyka śledcza jest tu niezbędna, choć postrzegana jest jako element fazy post-incydentalnej, gdy sam incydent jest już powstrzymany, a systemy zabezpieczone. Analitycy informatyki śledczej nie zajmują się reakcją na incydent, a raport informatyki śledczej dotyczący danego zdarzenia może powstać po jakimś czasie i należy do fazy lessons learnt zarządzania incydentem. Sprawa niby prosta ale patrząc na „życie” od razu nasuwa się pytanie czy ten model wykorzystania informatyki śledczej jest naprawdę skuteczny?

Nowy model bezpieczeństwa

Wróćmy do naszego przykładu. Wyobraźmy sobie, że telefon do pracownika niczego nie wyjaśnił. Pracownik pracował na swoim koncie i nie pamięta czy próbował logować się na drugie konto z uprawnieniami administracyjnymi. Nie jest też w stanie powiedzieć, czy miał jakieś problemy z capslock, a na pewno był przy komputerze w momencie zdarzenia. W sieci nie odnotowano również żadnych połączeń do podejrzanej stacji. Co zatem się stało? Może SIEM się pomylił? To mało prawdopodobne, a jeśli przyjrzymy się zdarzeniu to zobaczymy, że próby logowania nastąpiły lokalnie z konta podstawowego na konto administracyjne. A więc być może malware?

W tym wypadku właściwa reakcja nie jest możliwa bez stwierdzenia faktycznej przyczyny problemu. Zablokowanie stacji może być niewystarczające, bo atak może być bardziej złożony, a skala problemu znacznie większa. Zignorowanie indykatorów może oznaczać poważną kompromitację – jeśli malware posiada pulę haseł i tylko próbkował konto administracyjne na podejrzanej stacji to być może inne systemy są również zarażone? Zaangażowanie informatyków śledczych okazuje się tu niezbędne aby w ogóle wiedzieć jak reagować. Okazuje się, że w przypadku tego typu zagrożeń jesteśmy niezbędni już nie na końcu łańcucha reakcji ale tuż po wystąpieniu zdarzenia. Bez naszej diagnozy nie sposób przygotować właściwej odpowiedzi a nawet zdecydować czy mamy do czynienia z incydentem!

Zagrożenia malware, APT, itd. powodują, że model systemu bezpieczeństwa musi ewoluować. Informatyk śledczy stanie się ważnym elementem response. Nie oznacza to jednak, że będzie odpowiedzialny za reakcję. Jego rolą będzie dostarczenie wiedzy dla zespołu reakcji. Takie podejście całkowicie zmieni perspektywę, gdyż jak wiemy, czas pomiędzy zdarzeniem a wynikiem analizy i reakcją musi być maksymalnie krótki aby zapobiec wyciekowi informacji. To wymaga całkowitej przebudowy sposobu pracy systemu bezpieczeństwa. Poszczególne role w systemie bezpieczeństwa muszą ze sobą ściśle współpracować tak, aby zależności między zdarzeniami i incydentami, reakcją i analizą miały formę dynamiczną.

Taka ewolucja jest możliwa i w najbardziej zaawansowanej formie jest realizowana w Security Operations Center.

Tam sprawne połączenie procesów response i digital investigations daje w efekcie nieosiągalne w „tradycyjnym podejściu” możliwości. Włączenie analizy w proces response powoduje, że nawet najtrudniejsze zdarzenie może być dynamicznie zarządzane, a odpowiedź na dowolny incydent niemal natychmiastowa. Warunkiem jest jednak odpowiednie przygotowanie procesów, zespołów i narzędzi którymi się posługują tak, aby przepływ pracy był w pełni ustrukturyzowany, a świadomość sytuacyjna pełna. W efekcie wpływ procesu response na systemy prewencji osiąga niespotykane wcześniej możliwości.

Potwierdza to tezę o niezbędności informatyki śledczej w systemie bezpieczeństwa. Również jako Stowarzyszenie Instytut Informatyki Śledczej dostrzegamy coraz silniejszą zależność pomiędzy procesem response, a wykorzystaniem digital investigations. Stąd też nowa formuła naszej konferencji. W tym roku łączymy informatykę śledczą i bezpieczeństwo IT w dwóch równoległych ścieżkach tematycznych. Taka koncepcja pozwoli działom bezpieczeństwa zdobyć komplementarną wiedzę w obu tematach. Dzięki temu ich działanie zespołowe będzie zdecydowanie bardziej skuteczne. Również dobry informatyk śledczy musi rozumieć i znać rozwiązania security i związane z nimi możliwości analityczne. Dziś każdy z producentów rozwiązań zaczyna dostrzegać naszą rolę w procesie zapewnienia bezpieczeństwa informacji. Dlatego oprócz ochrony wprowadzają możliwości analityczne pozwalające na identyfikowanie nowych zagrożeń i aktywne podejście do problematyki zabezpieczeń.