Od pewnego czasu bardzo modnym terminem w środowisku IT security staje się SOC (Security Operations Center), czyli tzw. Operacyjne Centrum Bezpieczeństwa.

Ten trzyliterowy skrót przebija się do świadomości osób odpowiedzialnych za bezpieczeństwo nie tylko w dużych firmach, ale zaczyna być dostrzegana również w segmencie małych i średnich przedsiębiorstw, który w Polsce staje się istotnym rynkiem pod względem usług informatycznych.

Obecnie same narzędzia służące podnoszeniu szeroko rozumianego bezpieczeństwa informatycznego nie są już w stanie zapobiec coraz liczniejszym włamaniom, które są na tyle skomplikowane, iż często administratorzy mają problem ze zidentyfikowaniem miejsca ataku w ramach infrastruktury IT danej organizacji. Mowa tutaj o atakach typu APT (Advanced Persistent Threats) wykorzystywanych w długim okresie czasu do osiągnięcia celu jakim jest np. uzyskanie najważniejszych informacji dla danej organizacji. W związku z tym firmy coraz częściej decydują się na budowanie własnych SOC’ów w celu wczesnego wykrycia włamania, odparcia ataku, a na następnie przeprowadzenia dochodzenia, tak aby w przyszłości wyeliminować  potencjalne luki w zabezpieczeniach, a tym samym uszczelnić politykę bezpieczeństwa.

Dzisiaj chciałbym pokazać jak może wyglądać obsługa przykładowego incydentu przez operatorów w centrum bezpieczeństwa (SOC). Skupimy się na firmie z branży budowlanej. Dyrektor IT jako osoba z dużym doświadczeniem świadomy jest istniejącego ryzyka. Uzyskanie niewielkiej przewagi cenowej podczas przetargów może skutkować poważnymi konsekwencjami finansowymi. Kontrakty warte wiele milionów złotych mogą zostać przegrane ze względu na uzyskanie poufnych informacji przez konkurencję. Dlatego też zdecydował się na zwiększenie bezpieczeństwa poprzez wdrożenie odpowiednich rozwiązań jak i uruchomienie centrum, w którym operatorzy badają na co dzień stan zabezpieczeń w organizacji.

W skład SOC wchodzą 2 linie analityków oraz kierownik który bezpośrednio podlega pod dyrektora IT.

Ponieważ firma prowadzi kontrakty międzynarodowe cały zespół pracuje w trybie 24/7, tak aby na bieżąco reagować w przypadku wystąpienia incydentów. Całość pracy analityków opiera się na produktach oraz procedurach, które odpowiednio wdrożone umożliwiają szybką i poprawną reakcję na zagrożenia. SOC team podzielony jest na dwie linie analityków, które odpowiadają za identyfikację oraz eliminację pojawiających się zgłoszeń (alertów). Pierwsza linia (L1) skupia się przede wszystkim na potwierdzaniu czy zarejestrowane incydenty są faktycznie uzasadnione, natomiast linia druga (L2) potwierdza incydent oraz w zależności od sytuacji stara się wyeliminować zagrożenie.

Załóżmy, iż Pan Mariusz, niedawno przyjęty analityk (L1) wraca z obiadu, loguje się do systemu obsługi SOC – RSA Archer SecOps i widzi nowo wygenerowany incydent (rysunek 1).

01. Widok systemu RSA Archer w Security Operations Center Mediareocvery

Rysunek 1. Widok systemu RSA Archer.

Incydent został zarejestrowany na podstawie alarmu z systemu Bit9, który wykrył włożenie pendrive’a, a następnie skopiowanie i uruchomienie nowego pliku wykonywalnego. Po wejściu w szczegóły incydentu Pan Mariusz widzi, iż alarm pochodzi z laptopa prezesa firmy. Odpowiedni priorytet incydentu został nadany na podstawie wcześniej określonych zasobów IT firmy. W incydencie została zawarta procedura obsługi,  która jasno wskazuje co w tym przypadku analityk powinien wykonać. Sprawdza pierwszy etap i otrzymuje informację, iż powinien upewnić się czy stacja robocza faktycznie wykonuje podejrzane połączenia od momentu wykrycia incydentu. Jeżeli tak, analityk L1 powinien eskalować zadanie na poziom L2. W zgłoszeniu został umieszczony link do systemu RSA Security Analytics, który umożliwia bezpośrednie i szybkie sprawdzenie ruchu sieciowego z podejrzanego hosta, po zalogowaniu się widzi, iż w ruchu przesyłanym z podejrzanego laptopa system FireEye NX wykrył i zaraportował komunikację do serwera C&C (rysunek 2).

02. Szczegółowy widok na log z systemu FireEye NX w RSA Security Analytics w Security Operations Center Mediareocvery

Rysunek 2. Szczegółowy widok na log z systemu FireEye NX w RSA Security Analytics.

Daje więc to podstawę do potwierdzenia możliwej infekcji na laptopie prezesa. Pan Mariusz uzupełnia więc zgłoszony incydent o uzyskane informacje (dołącza link do systemu RSA SA, tak aby analityk L2 był w stanie szybko sprawdzić podjęte działania). W tym momencie jako, iż jest pracownikiem z mniejszymi uprawnieniami jego praca zostaje zakończona. Eskaluje więc incydent bezpośrednio do drugiej linii (L2), tak aby odpowiednio doświadczone osoby mogły zająć się rozwiązaniem problemu. Po wykonaniu tego zadania przechodzi do obsługi kolejnego zgłoszenia. Czas wymagany na realizacje zadania został zarejestrowany na podstawie uzupełnionych danych. Jest to o tyle istotne, iż daje kierownikowi SOC ważne informacje odnośnie czasochłonności na poszczególnych stanowiskach, jak i umożliwia sprawdzanie które typy incydentów są rozwiązywane wolno i co za tym idzie jakie kroki może podjąć kierownik aby zwiększyć efektywność swoich pracowników.

Wracając do problemu, analityk drugiej linii (L2) przystępuje do obsługi incydentu, w pierwszym kroku sprawdza co zostało wykonane na pierwszej linii (L1)  i jakie są wnioski. Po zapoznaniu się z informacjami przystępuje do kolejnego etapu procedury, który polega na analizie malware’u znajdującego się na komputerze oraz potwierdzeniu czy inne stacje robocze w tym momencie nie są zainfekowane podobnym złośliwym oprogramowaniem. Do tego zadania mają zostać wykorzystane narzędzia RSA ECAT oraz FireEye AX.

Analityk L2 – Pani Anna sprawdza więc nazwę komputera oraz IP, z którego został wygenerowany podejrzany ruch i loguje się na konsolę systemu ECAT.  Już po chwili zauważa, iż interesujący ją komputer otrzymał wysoki wskaźnik punktowy (rysunek 3).

Rysunek 3. Ogólny widok na status maszyny w systemie RSA ECAT.

Po wejściu w szczegóły widzi, iż uruchomiony został plik o nazwie comet.exe który uzyskał wysoką ocenę punktową (rysunek 4).

04. Szczegółowy widok stanu hosta w RSA ECAT w Security Operations Center Mediareocvery

Rysunek 4. Szczegółowy widok stanu hosta w RSA ECAT

Analityk otrzymuje informację dlaczego taki wynik został przypisany. Plik po uruchomieniu modyfikował w systemie ustawiania LUA, polityki firewall’a, skopiował się do ukrytego katalogu oraz uruchomił dodatkowo proces w systemie. W zakładce „Paths” analityk widzi jakie nazwy plików są powiązane ze sobą w tym wypadku, a w zakładce „Tracking” może dokładnie prześledzić ścieżkę zmian. Ponieważ firma zainstalowała oprogramowanie ECAT na wszystkich laptopach i serwerach, Pani Anna w zakładce „Machines”, zauważa, obecnie ten plik oraz proces znajduje się tylko na jednym komputerze. Zapisuje więc tę informację w dzienniku incydentu, aby po chwili przystąpić do analizy malware’u. Dodatkowo upewnia się czy dany plik nie był widoczny wcześniej w sieci firmowej, kopiuje sumę MD5 i zakłada filtr w systemie Bit9, który wskaże jej gdzie jeszcze mógł znajdować się podejrzany plik (rysunek 5).

Rysunek 5. Szczegółowy widok statusu pliku w systemie Bit9

Rysunek 5. Szczegółowy widok statusu pliku w systemie Bit9

Mając potwierdzenie z systemu Bit9 iż plik znajduje się obecnie tylko na jednym stacji roboczej Pani Anna wykorzystuje integrację systemów Bit9 oraz FireEye AX i przesyła plik bezpośrednio do analizy.
Po kilku minutach loguje się do systemu FireEye AX i sprawdza wynik zadania, otrzymuje potwierdzenie, iż plik faktycznie jest zagrożeniem dla systemów.

Może również zapoznać się ze szczegółową analizą malware’u, która pokazuje krok po kroku jak zachowuje się podejrzane oprogramowanie (rysunek 6).

Rysunek 6. Szczegółowy raport z analizy malware w systemie FireEye AX

Rysunek 6. Szczegółowy raport z analizy malware w systemie FireEye AX

 

Tak więc w tym momencie Pani Anna posiada już potwierdzenie, faktycznie na laptopie prezesa zostało uruchomione szkodliwe oprogramowanie, które próbowało wykonać połączenie do serwera C&C (połaczenie te zablokował system FireEye NX). Malware został zidentyfikowany jako Backdoor.Darkcomet, już po chwili analityk L2 wyszukuje informację o tym zagrożeniu, okazuje się, iż jest to popularny zestaw narzędzi typu RAT (Remote Access Tool). System FireEye AX jest ogromnym wsparciem dla analityków malware’u, gdyż umożliwia wykonanie analizy w ciągu kilku lub kilkunastu minut, normalnie ta praca zajęłaby osobie z odpowiednim doświadczeniem nawet kilka godzin pracy.

Informacje o potwierdzonym zagrożeniu jak i plikach obecnych w systemach zostają zapisane w dzienniku incydentów. W tym momencie analityk przechodzi do trzeciego etapu zapisanego w procedurach, który nakazuje przeprowadzenie dochodzenia na zainfekowanych stacjach roboczych w celu sprawdzenia czy faktycznie doszło do wycieku danych. W tym celu Pani Anna wykorzysta narzędzie RSA Security Analytics. Dzięki logowaniu całego ruchu sieciowego będzie w stanie sprawdzić czy nastąpiło połączenie do zewnętrznych serwerów i czy zostały przesłane jakieś dane. Wykorzystując wbudowany link w alercie do systemu RSA SA szybko filtruje potrzebne informacje, widzi iż system zarejestrował połączenia do zewnętrznego hosta C&C (zidentyfikowane przez system FireEye NX), filtruje widok pakietów sieciowych tak, aby potwierdzić wyciek.

Analityk potwierdza, iż pomimo próby nawiązania połączenia nie została zestawiona sesja oraz nie zostały przesłane dane na zewnątrz (zerowy payload w pakietach). Wgląd w pakiety sprawia że, w przypadku zagrożenia firma ma możliwość odtworzenia ruchu sieciowego, co daje spore możliwości pod kątem analizy wycieku. Dzięki temu możemy szybko zlokalizować pliki, które zostały wysłane (oczywiście jeżeli wcześniej nie zostały zaszyfrowane przez malware). Inną ciekawą funkcją systemu jest możliwość odtworzenia przeglądanych stron www, podglądu plików graficznych, nagrywanie rozmów VoIP na poziomie pakietów. Daje to spore możliwości analizy zdarzeń dla osób odpowiedzialnych za bezpieczeństwo IT w przedsiębiorstwach.

Po potwierdzeniu, iż faktycznie nie mieliśmy wycieku danych w firmie, Pani Anna uzupełnia dziennik incydentu i przechodzi do czwartego, ostatniego już etapu procedury. Jej zadaniem jest w tym momencie oczyszczenie laptopa zainfekowanego w tym momencie, wykorzysta w tym celu system EnCase CyberSecurity, który dzięki współpracy z systemem FireEye NX w momencie wykrycia połączenia callback do serwera C&C z laptopa prezesa, wykonał snapshoot maszyny, co sprawia, że mamy możliwość usunięcia złośliwego malware’u ze stacji (rysunek 7).

Po usunięciu złośliwego kodu, analityk uzupełnia informacje w dzienniku incydentów. W tym momencie zamyka również jego obsługę. Całe zadanie od momentu otrzymania alertu do rozwiązania problemu zostało sprawnie wykonane dzięki doświadczeniu osób zatrudnionych w SOC jak i procedurom, które odpowiednio prowadziły analityków w tym przypadku. Kierownik IT dzięki swojemu widokowi w systemie RSA Archer na bieżąco jest w stanie monitorować status zadań, widzi trendy historyczne. Dlatego jest w stanie odpowiednio reagować na pojawiające się problemy. Dzięki swojej pracy jest w stanie utworzyć odpowiednie polityki reagowania na poszczególne zagrożenia. Sam system Archer również posiada funkcjonalność przekazywania zmiany, co w przypadku pracy w trybie 24/7 jest dosyć istotne, aby osoby zatrudnione w SOC mogły od razu zajmować się najważniejszymi w tym momencie incydentami.

Rysunek 7. Widok opcji wykonanego snapshoot’u z systemu EnCase CyberSecurity.

Rysunek 7. Widok opcji wykonanego snapshoot’u z systemu
EnCase CyberSecurity.

W opisie tego przykładowego incydentu i sposobu jego obsługi przyjąłem pewne założenia.

System Bit9 jest ustawiony w polityce zezwalającej na uruchomienie każdej aplikacji na stacji końcowej, czyli laptop prezesa nie jest odpowiednio chroniony. Niestety często spotykamy się przy prawdziwych analizach z bardzo wieloma przypadkami luźnego podejścia do bezpieczeństwa przez osoby decyzyjne w przedsiębiorstwach. Gdyby system ten był poprawnie wdrożony mielibyśmy możliwość wcześniejszej automatycznej analizy nowego pliku w systemie FireEye AX. Dzięki temu uruchomienie tego oprogramowania zostałoby zablokowane na wszystkich stacjach roboczych w organizacji po potwierdzeniu jego szkodliwości. Cały proces obsługi incydentu jest jedynie przykładem w jaki sposób praca SOC może być zorganizowana. Ten artykuł jest jedynie wstępem do budowy polityk i procedur pracy SOC, które muszą być zawsze indywidualnie przystosowane do każdego klienta. Mam nadzieję, iż udało mi się pokazać jak może wyglądać obsługa jednej z takich procedur.

Oceń artykuł