Dziś, kiedy prawie wszystko jest połączone z Internetem, ochrona przed cyberatakami jest ważniejsza niż kiedykolwiek wcześniej. Słyszymy codziennie o nowych atakach hakerów, wyciekach danych lub wirusach. Aby temu przeciwdziałać, firmy na całym świecie tworzą zespoły specjalistów, których zadaniem jest monitorowanie i ochrona systemów – to właśnie Security Operations Center, czyli SOC.
W SOC pracują analitycy bezpieczeństwa, którzy na co dzień zajmują się wykrywaniem i analizowaniem zagrożeń. Ich działania są niezbędne dla bezpieczeństwa cyfrowego firmy. Na czym dokładnie polega ich praca? Jak wygląda ich dzień i co się dzieje, kiedy wykryją jakieś zagrożenie?
Rola analityka SOC
Analityk SOC to osoba odpowiedzialna za monitorowanie, wykrywanie i reagowanie na zagrożenia bezpieczeństwa w systemach informatycznych. Do głównych obowiązków należy:
1. Monitorowanie systemów:
Stale monitorowanie systemów i sieci organizacji za pomocą specjalistycznych narzędzi jest niezbędnym minimum, aby wykryć wszelkie podejrzane aktywności.
2. Analiza alertów:
Gdy systemy monitorujące wykryją potencjalne zagrożenie, analitycy analizują alerty, aby ocenić, czy są one rzeczywistym zagrożeniem, czy fałszywym alarmem.
3. Kategoryzacja i priorytetyzacja incydentów:
Incydenty są kategoryzowane i priorytetyzowane na podstawie ich potencjalnego wpływu na organizację. Najbardziej krytyczne incydenty są analizowane i rozwiązywane w pierwszej kolejności.
4. Reakcja na incydenty:
Analitycy podejmują działania mające na celu neutralizację zagrożeń, takie jak izolacja zainfekowanych urządzeń, blokowanie podejrzanych adresów IP czy usuwanie złośliwego oprogramowania.
5. Dokumentacja:
Każdy incydent musi być dokładnie udokumentowany. Analitycy sporządzają raporty, które opisują przebieg incydentu, podjęte działania oraz wnioski na przyszłość.
6. Współpraca z innymi zespołami:
Analitycy SOC często współpracują z innymi zespołami w organizacji, m.in. zespołami IT, administratorami, zespołami odpowiedzialnymi za infrastrukturę czy zarządzanie ryzykiem, aby skutecznie reagować na incydenty i wdrażać odpowiednie środki zaradcze.
Narzędzia i technologie wykorzystywane przez analityków SOC
Analitycy SOC korzystają z różnych narzędzi i technologii, aby skutecznie wykonywać swoje zadania:
SIEM (Security Information and Event Management):
Narzędzie do zbierania, analizowania i korelowania danych z różnych źródeł, aby wykrywać potencjalne zagrożenia np. SecureVisio czy Splunk.
EDR (Endpoint Detection and Response):
Narzędzie do monitorowania i analizy aktywności na końcówkach (np. komputerach, serwerach) w celu wykrywania i reagowania na zagrożenia.
IDS/IPS (Intrusion Detection/Prevention Systems):
Systemy wykrywające i zapobiegające włamaniom do sieci.
Firewall i systemy ochrony przed złośliwym oprogramowaniem:
Narzędzia do ochrony sieci i urządzeń przed nieautoryzowanym dostępem i złośliwym oprogramowaniem.
Narzędzia do analizy ruchu sieciowego:
Umożliwiają szczegółową analizę ruchu w sieci, co pomaga w identyfikacji podejrzanych aktywności.
Codzienne zadania analityka SOC
Praca analityka SOC jest często postrzegana dwojako: jako praca monotonna i dynamiczna. Pomimo przeciwności tych dwóch pojęć, zazębiają się one i tworzą spójną całość.
Zdecydowanie monotonnością można określić codzienną weryfikację systemów monitorujących, np. systemów SIEM. Zdecydowana większość alertów w systemach bezpieczeństwa, po krótkiej analizie będzie fałszywym alarmem. Codzienna weryfikacja podobnych alertów prowadzi do monotonni, co jest jednym z problemów branży. Ta powtarzalność alertów może być przyczyną niezauważenia małego szczegółu, który mógłby zmienić klasyfikację zdarzenia z fałszywego alarmu na incydent bezpieczeństwa. Stąd w takich warunkach istotne jest utrzymywanie wysokiego poziomu skupienia i uważności.
Z drugiej strony, w świecie cyberbezpieczeństwa nie brakuje dynamiki. Codziennie publikuje się dziesiątki nowych podatności. W samym czerwcu opublikowano ponad 3000 nowych podatności. Trend rok do roku jest wzrostowy. Dla porównania, w roku 2022 odnotowano 25 tysięcy nowych podatności, rok później liczba ta wzrosła do 29 tysięcy. Przez ostatnie pół roku opublikowano niemal 21 tysięcy podatności. Jest to taka sama ilość jaką odnotowano za cały 2021 rok, a zaczęliśmy dopiero drugą połowę 2024 roku.
Liczba nowych podatności – stan na dzień 03.07.2024 (https://www.cvedetails.com/browse-by-date.php)
Praca analityka SOC również polega na proaktywności. Kluczową rolę odgrywa Cyber Threat Intelligence (CTI), który dostarcza cennych informacji o aktualnych zagrożeniach. CTI gromadzi i analizuje dane z różnych źródeł, takich jak raporty o zagrożeniach, bazy danych złośliwego oprogramowania, fora hakerskie oraz analizy zewnętrznych firm bezpieczeństwa. Dzięki tym informacjom analitycy SOC mogą przeprowadzać threat hunting (aktywne poszukiwanie zagrożeń), identyfikować nowe zagrożenia zanim staną się one realnym problemem dla organizacji, oraz dostosowywać strategie obronne w celu minimalizacji ryzyka.
Jednak mimo proaktywnego podejścia i zaawansowanych narzędzi, nie wszystkie zagrożenia mogą być wykryte i powstrzymane na czas. Kiedy dochodzi do incydentu bezpieczeństwa, analitycy SOC muszą działać szybko i skutecznie, aby zminimalizować jego wpływ. Jak wygląda analiza incydentu bezpieczeństwa? Jakie kroki podejmują analitycy w praktyce i z jakich narzędzi korzystają w procesie reakcji na incydent?
Przykład analizy incydentu
Jako przykład posłuży nam zdarzenie zarejestrowane w środowisku klienckim. Podczas regularnej aktywnosci typu threat hunting, mającej na celu wykrycie odstępstw od normy, potencjalnych zagrożen lub innego rodzaju aktywności, które wymagaja dodatkowych akcji ze strony SOC natrafilśmy na potencjalny indykator wskazujący na zagrożenie kompromitacji serwera webowego.
Wstępna analiza
Na załączonym poniżej logu widzimy request typu GET z adresu 45.X.X.X do serwera WWW. Ciąg znaków wskazuje na atak typu „Directory Traversal”. Następnie możemy dostrzec polecenie odkodowania zakodowanego w base64 ciągu, którego odkodowana zawartość jest przekierowywana do nowego pliku z.php.
W ostatniej linijce widzimy wartość „200”. Jest to odpowiedź od serwera WWW na request, gdzie 200 to odpowiedź „OK” – na tym etapie wiemy, że połączenie doszło do skutku.
W nastepnym etapie wykonaliśmy analizę powyższego skryptu. Odkodowaliśmy ciąg base64 a jego zawartość widzimy poniżej:
Skrypt ma na celu nawiązanie połączenia z serwerem C2, następnie pobranie pliku „x”.
Analiza reputacji adresu IP w zewnętrznych bazach reputacyjnych VirusTotal oraz AbuseIPDB wskazała, że adres jest sklasyfikowany jako potencjalne zagrożenie. Zgłoszenia oraz raporty użytkowników były aktualne oraz wpływały na bieżąco.
W związku z wysokim prawdopodbieństem infekcji serwera, ze względu na odpowiedź „200” ze strony serwera, potwierdzeniem w bazach danych negatywnej reputacji adresu IP, nowe raporty sugerujące że ataki są wykonywane na bieżąco, przystąpiliśmy do procedury reakcji na incydent (incident response), której celem jest zminimalizowanie skutków potencjalnego ataku, a jedną z pierwszych decyzji było szybkie odcięcie serwera od internetu oraz blokadzie podejrzanego adresu.
Dalsza analiza skupiła się na potwierdzeniu ruchu sieciowego do serwera WWW. Zweryfikowane zostało, że adres atakującego łączył się z serwerem jedynie w przedziale incydentu, nie odnotowano wcześniejszych prób połączeń.
Następnie nastąpiła weryfikacja plików na serwerze. Nie odnotowano plików „z.php” oraz „x” na serwerze, natomiast istniało duże prawdopodobieństwo, że dane pliki były nadal obecne lecz pod zmienioną nazwą bądź pobrały następny payload a następnie samodzielnie się usunęły.
W związku z brakiem plików na serwerze, podjęto analizę pliku „x”, który próbował pobrać atakujący ze swojego serwera. Plik pełni funkcję droppera, ma na celu pobranie malware „redtail” na zaatakowany serwer.
Analiza wróciła do weryfikacji logów z samego serwera. Dostępne logi zostały zweryfikowane przez zespół SOC. Odkryto w nich kolejny request, tym razem do wcześniej wspomnianego, potencjalnie zdroppowanego pliku „z.php”.
Atakujący, po wcześniejszej odpowiedzi „200” od serwera, próbował odzyskać plik „z.php”, co równocześnie równałoby się z wykonaniem zawartego w nim kodu pobierającego plik „x” na serwer. W tym przypadku serwer zwrócił odpowiedź „404”, oznaczającą brak pliku na serwerze. Dodatkowo potwierdza to kod błędu zarejestrowany w logach serwera.
Jednym z ostatnich kroków jakie zostały podjęte to weryfikacja wszystkich logów z serwera w celu upewnienia się, że na pewno atakujący nie uzyskał dostępu do serwera. Otrzymane od klienta pełne logi zostały przeszukane pod kątem występowania plików „z.php”, „x”, „redtail” oraz występowania adresu IP atakującego. Zostały zwrócone informacje znane nam wcześniej.
W związku z brakiem śladów pliku „z.php” w logach aktywności serwera, nie mógł się pojawić plik „x” oraz plik „redtail”.
W ostatnim kroku zespół SOC Trecom utworzył oraz przekazał klientowi rekomendacje wraz z krótkim podsumowaniem oraz całym raportem incydentu.
Podsumowanie
W dobie powszechnych zagrożeń systemów IT prowadzących do zawsze daleko idących konsekwencji, ale także regulacji i konieczności zadbania o zgodność z nimi, tylko odpowiednie i prawidłowo wdrożone technologie, wspierane przez właściwe procesy, realizowane kwalifikowanym personelem, mogą zapewnić wyższy poziom bezpieczeństwa. Takie funkcje realizują zespoły Security Operation Center, takie jak SOC Trecom. Zapraszamy do współpracy.
Autor: Przemysław Szalwa — analityk bezpieczeństwa. Jego pasją są OSINT oraz CTI, koty oraz produkcja muzyki.