Analityk SOC rzadko od razu widzi cyberatak od początku do końca. Najczęściej otrzymuje pojedynczy sygnał: nietypowe logowanie, uruchomienie skryptu, połączenie z rzadko spotykanym adresem IP albo nagły wzrost transferu danych. Każde z tych zdarzeń może wiązać się z zagrożeniem, jak i mieć zupełnie niewinne wyjaśnienie. Dopiero ich zestawienie pozwala sprawdzić, czy tworzą spójną historię i co oznaczają.

Z perspektywy analityka telemetria, czyli dane dostarczane przez różne systemy cyberbezpieczeństwa, przypomina zbiór poszlak. Im więcej wiarygodnych śladów z różnych części środowiska, tym większa szansa, że będzie można połączyć pojedyncze obserwacje w spójny obraz zdarzenia. By jednak dane telemetryczne były użyteczne, trzeba zadbać o odpowiednie pokrycie najważniejszych obszarów środowiska, właściwą konfigurację źródeł oraz jakość i retencję informacji. Nie oznacza to zbierania wszystkiego, co technicznie możliwe: nadmiar danych tworzy szum i generuje koszty, natomiast zbyt wąska telemetria może pozostawić luki, których podczas późniejszej analizy nie da się już uzupełnić. To właśnie od tych decyzji zależy, czy po wykryciu podejrzanej aktywności analityk otrzyma materiał pozwalający odtworzyć przebieg zdarzeń, czy jedynie kilka niepowiązanych fragmentów.

Alert – i co dalej?

Alert jest punktem wyjścia do analizy. Może zostać wygenerowany na podstawie ustalonej reguły lub znanej techniki ataku, ale w nowoczesnych systemach EDR dużą rolę odgrywają także mechanizmy behawioralne. Nie oceniają one wyłącznie pojedynczego zdarzenia, lecz analizują całe łańcuchy powiązanej aktywności i szukają nietypowych wzorców zachowania. O ile więc samo pojawienie się lub uruchomienie pliku nie musi oznaczać zagrożenia, to duże znaczenie ma to, co wydarzy się później: jakie procesy plik uruchomi, jakie polecenia wykona, z czym nawiąże komunikację i jakie zmiany wprowadzi w systemie. Alert wskazuje zatem aktywność wymagającą uwagi, ale nie przesądza jeszcze, że rzeczywiście doszło do naruszenia bezpieczeństwa.

Od alertu do hipotezy

Kiedy analizujemy alert, najpierw próbujemy ustalić, z jakiego rodzaju aktywnością mamy do czynienia. Czy zdarzenie dotyczy użytkownika, urządzenia, procesu czy usługi? Co wydarzyło się wcześniej? Czy podobna aktywność pojawiła się w innych miejscach? I wreszcie: czy istnieje uzasadnienie biznesowe, które mogłoby ją wyjaśnić?

Nietypowe logowanie może oznaczać przejęcie konta, ale może też wynikać z użycia VPN albo podróży pracownika. Skrypt uruchomiony z podwyższonymi uprawnieniami może być elementem ataku, lecz równie dobrze częścią zaplanowanych prac administracyjnych. Zadaniem analityka jest tutaj zbudowanie kilku możliwych hipotez i sprawdzenie, która z nich najlepiej pasuje do dostępnych danych.

W SOC360 częstym punktem wyjścia do analizy są zgłoszenia oparte na metadanych, których nie rozpoznają dostępne źródła Cyber Threat Intelligence. Sam brak takiego rozpoznania nie przesądza jednak ani o bezpieczeństwie pliku, ani o jego złośliwym charakterze – zwłaszcza że zmiana metadanych współczesnego malware jest bardzo prosta. Dlatego każde takie zdarzenie wymaga indywidualnej analizy. W drzewie procesów możemy na przykład zobaczyć pobranie archiwum, wypakowanie jego zawartości, uruchomienie pliku i rozpoczęcie instalacji. Taki przebieg może dotyczyć zarówno legalnego oprogramowania, jak i pliku pochodzącego z niezweryfikowanego źródła, dlatego dopiero dalsza analiza telemetrii pozwala właściwie zaklasyfikować zdarzenie.

Jak analityk weryfikuje podejrzenia?

Aby rozstrzygnąć, z którym scenariuszem mamy do czynienia, zaczynamy poszerzać kontekst. Sprawdzamy, skąd został pobrany plik, jaka aktywność użytkownika poprzedzała pobranie oraz jakie procesy, skrypty i polecenia zostały uruchomione podczas instalacji. Telemetria może wówczas ujawnić kolejne istotne ślady, na przykład nietypowe połączenia sieciowe, uruchomienie dodatkowych skryptów czy pobieranie kolejnych komponentów.

Każda z tych informacji pozwala zweryfikować wcześniejsze założenia. Część hipotez możemy odrzucić, inne wymagają dalszego sprawdzenia, czasem również analizy samego pliku. Dopiero po zestawieniu tych obserwacji możemy z większą pewnością określić, czy mamy do czynienia z legalnym oprogramowaniem, nietypowym, ale dopuszczalnym działaniem użytkownika, czy też rzeczywistym zagrożeniem.

Dobre śledztwo zaczyna się od właściwej widoczności

Żeby jednak móc weryfikować hipotezy w sposób opisany powyżej, analityk musi mieć dostęp do odpowiednich danych. To, ile jesteśmy w stanie ustalić po pojawieniu się alertu, zależy bowiem nie tylko od naszych kompetencji, ale również od tego, które części środowiska są obserwowane i jaką telemetrię udostępniają wykorzystywane systemy.

Każde źródło pokazuje inny fragment historii

Nie istnieje jedno narzędzie, które pokaże cały przebieg ataku. EDR pozwala zajrzeć w aktywność urządzenia końcowego, NDR obserwuje komunikację sieciową, systemy ochrony tożsamości dostarczają informacji o kontach i uwierzytelnianiu, a logi aplikacyjne pokazują, co dzieje się wewnątrz konkretnej usługi. Każda z tych klas systemów obserwuje inne rodzaje aktywności i wykorzystuje inne mechanizmy detekcji. Z perspektywy SOC są to więc uzupełniające się punkty obserwacji, a nie rozwiązania, które można dowolnie zastępować.

Ma to szczególne znaczenie, ponieważ współczesne ataki trudno zamknąć w jednym, z góry przewidzianym scenariuszu. Atakujący często wykorzystują legalne komponenty systemowe, tzw. LOLBins (Living-off-the-Land Binaries), narzędzia RMM (Remote Monitoring and Management) czy inne oprogramowanie administracyjne. Ich użycie nie musi wcale oznaczać zagrożenia. Dopiero nietypowy kontekst lub ciąg powiązanych zdarzeń może wskazać aktywność wymagającą dalszej analizy. Dlatego tak istotne są systemy wykorzystujące mechanizmy behawioralne, które potrafią wychwytywać anomalie w sposobie działania użytkowników, procesów i urządzeń.

Co się dzieje, gdy brakuje jednej perspektywy?

W praktyce największym ograniczeniem podczas analizy jest brak całościowego oglądu sytuacji. Jeśli organizacja chroni urządzenia jedynie za pomocą antywirusa lub nawet rozwiązania typu next-generation antivirus, może skutecznie blokować część znanych złośliwych plików, ale nie otrzyma szczegółowej telemetrii potrzebnej do prześledzenia bardziej złożonego łańcucha zdarzeń. Fragment historii po prostu pozostaje niewidoczny.

Bez EDR trudno odtworzyć, jakie procesy zostały uruchomione, z jakimi poleceniami i w jakiej relacji do wcześniejszych zdarzeń. Podobnie sam NDR może wskazać podejrzaną komunikację, ale bez telemetrii ze stacji roboczej lub serwera nie zawsze pozwoli ustalić, co na urządzeniu ją zainicjowało.

Jeszcze wyraźniej widać to przy kompromitacji aplikacji webowej, wynikającej na przykład z podatności w WordPressie. Logi aplikacyjne pokazują zdarzenia zachodzące w warstwie aplikacji, natomiast EDR pozwala prześledzić aktywność na poziomie systemu operacyjnego. Dopiero zestawienie obu perspektyw daje pełniejszy obraz incydentu. Brak jednego z tych źródeł pozostawia lukę w analizie, a brak obu może ograniczyć ją niemal wyłącznie do artefaktów pozostawionych na maszynie.

W SOC360 widoczność rozumiemy więc nie jako liczbę wdrożonych produktów, lecz jako możliwość spojrzenia na zdarzenie z kilku uzupełniających się perspektyw. Każdy nieobserwowany obszar tworzy potencjalną czarną dziurę. W praktyce podczas jednej analizy często przechodzimy między kilkoma takimi perspektywami. Alert z EDR może zwrócić uwagę na nietypowy proces, dane z NDR mogą pokazać, z jakim adresem komunikowało się urządzenie, a system ochrony tożsamości pomóc ustalić, z jakiego konta wykonano wcześniejsze działania. Każde źródło odpowiada wtedy na inne pytanie, a ich zestawienie pozwala zbudować bardziej wiarygodny obraz zdarzenia.

Samo posiadanie odpowiednich systemów nie gwarantuje, że tę widoczność rzeczywiście mamy. Narzędzie może być wdrożone, a mimo to nie zbierać części dostępnej telemetrii, pracować tylko na wybranych urządzeniach albo przekazywać dane w ograniczonym zakresie. Kolejnym pytaniem nie jest więc już tylko „czy mamy właściwe źródło?”, ale również „czy to źródło rzeczywiście pokazuje nam wszystko, co powinno?”.

Wdrożony system nie zawsze oznacza pełną widoczność

Samo zainstalowanie narzędzia nie gwarantuje jeszcze widoczności. System musi zostać właściwie skonfigurowany i zintegrowany z pozostałymi elementami środowiska, a później utrzymywany w taki sposób, aby rzeczywiście otrzymywał dane potrzebne do analizy.

Problemy nie zawsze wynikają przy tym z konfiguracji samego systemu bezpieczeństwa: agent może działać tylko na części urządzeń, konto integracyjne nie mieć odpowiednich uprawnień, konektor pobierać jedynie wybrane kategorie zdarzeń, a infrastruktura może być skonfigurowana w taki sposób, że część danych w ogóle nie trafia do narzędzia. Innym razem dane są dostępne, ale przechowywane zbyt krótko albo w formie utrudniającej powiązanie zdarzeń pochodzących z różnych źródeł - pojawia się tu problem balansu między długą retencją danych a jej kosztem.

NDR może działać poprawnie, a mimo to nie widzieć ruchu

Dobrym przykładem jest NDR. Sam system może być wdrożony i prawidłowo skonfigurowany, ale jeżeli urządzenia sieciowe nie przekazują do niego kopii odpowiedniego ruchu, część komunikacji pozostaje poza jego polem widzenia. Problem może ujawnić się dopiero podczas analizy incydentu: alert z EDR wskazuje podejrzaną aktywność na urządzeniu, więc chcemy sprawdzić jej kontekst sieciowy, ale w NDR nie znajdujemy potrzebnych danych. Nie dlatego, że rozwiązanie nie działa, lecz dlatego, że interesujący nas ruch nigdy do niego nie dotarł.

W rezultacie organizacja może mieć poczucie, że dany obszar jest monitorowany, podczas gdy dopiero realna analiza ujawnia lukę w widoczności. Przypomina to kamerę, która została zamontowana i działa poprawnie, ale nie obejmuje miejsca, które później okazuje się kluczowe dla śledztwa.

Dlatego konfiguracja telemetrii nie powinna być traktowana jako jednorazowy etap wdrożenia. Środowisko zmienia się wraz z aktualizacjami, migracjami, nowymi usługami i modyfikacjami infrastruktury. To, co kilka miesięcy wcześniej zapewniało odpowiednią widoczność, z czasem może zacząć dostarczać tylko wycinek potrzebnych informacji.

Najgroźniejsza czarna dziura to taka, której nikt nie zauważa

Niektóre problemy ze źródłami telemetrii są stosunkowo łatwe do wykrycia. Gdy wygasa klucz API, zatrzymuje się agent albo konektor traci połączenie, system może wygenerować alert techniczny. Zespół otrzymuje wówczas jasny sygnał, że widoczność została ograniczona.

Bardziej niebezpieczne są awarie, które nie powodują żadnego powiadomienia. Źródło może przestać wysyłać dane całkowicie albo przekazywać ich znacznie mniej, mimo że integracja nadal wygląda na aktywną. Przyczyną bywa zmiana konfiguracji, aktualizacja, nowy format zdarzeń, błędne filtrowanie lub częściowe uszkodzenie połączenia. W skrajnym przypadku do ograniczenia telemetrii może również doprowadzić napastnik.

Dla analityka cisza w danych jest dwuznaczna. Może oznaczać, że nic się nie wydarzyło, ale może też świadczyć o utracie widoczności. Jeżeli organizacja nie kontroluje ciągłości napływu informacji, łatwo pomylić te dwie sytuacje.

W SOC360 wykorzystujemy własny silnik analizy statystycznej, który pomaga wykrywać anomalie w sposobie napływania danych. Zwraca uwagę między innymi na nagłe zatrzymanie strumienia zdarzeń, nietypowy spadek ich liczby lub zmianę częstotliwości względem wcześniejszego profilu źródła. Dzięki temu możemy zauważyć problem również wtedy, gdy monitorowany system nie wygenerował własnego alertu technicznego.

Sam system nie zareaguje za organizację

Nawet prawidłowo wdrożone rozwiązanie nie zapewnia bezpieczeństwa, jeśli generowane przez nie sygnały nie są stale analizowane, a organizacja nie ma możliwości odpowiednio szybkiej reakcji.

Spotkaliśmy się z przypadkiem organizacji, która zgłosiła się do nas już po zaszyfrowaniu środowiska. Miała wdrożony wysokiej klasy system bezpieczeństwa, jednak nikt nie monitorował go w sposób ciągły, a skonfigurowane polityki nie przewidywały aktywnej automatycznej reakcji w przypadku wykrycia podejrzanych plików. W efekcie sam fakt posiadania zaawansowanego narzędzia nie wystarczył, aby zatrzymać rozwijający się atak.

Telemetria i alerty zaczynają mieć wartość operacyjną dopiero wtedy, gdy ktoś potrafi je właściwie ocenić i wystarczająco szybko przełożyć na działanie.

Od telemetrii do decyzji – rola analityka SOC

Sama telemetria, nawet najlepszej jakości, nie daje jeszcze odpowiedzi na pytanie, co właściwie wydarzyło się w środowisku. Dostarcza pojedynczych śladów, które analityk musi ze sobą połączyć, aby ustalić, skąd rozpoczęła się podejrzana aktywność, jakie kolejne działania zostały wykonane, jak daleko napastnik dotarł i czy zdołał utrzymać dostęp do środowiska.

Celem analizy nie jest przy tym wyłącznie ustalenie, czy doszło do ataku. Musimy również odpowiedzieć na pytania potrzebne do reakcji: gdzie rozpoczął się incydent, jaki jest jego zakres, czy napastnik nadal ma dostęp i jakie działania należy podjąć, aby skutecznie przerwać jego aktywność oraz ograniczyć skutki zdarzenia.

Właśnie tutaj pojawia się wartość pracy analityka SOC. Systemy dostarczają telemetrii, wykrywają anomalie i generują alerty, ale to analityk łączy rozproszone informacje w spójną historię i na jej podstawie wskazuje, co powinno wydarzyć się dalej.

Czy Twoja telemetria dostarczy potrzebnych danych, gdy dojdzie do incydentu?

Gotowość telemetrii nie zależy od samej liczby wdrożonych systemów. Warto sprawdzić przede wszystkim, czy organizacja ma wystarczającą widoczność, czy źródła działają prawidłowo i czy zebrane dane mogą zostać wykorzystane podczas realnej analizy.

• Czy monitoring obejmuje najważniejsze warstwy środowiska: urządzenia końcowe, sieć, tożsamości, aplikacje i chmurę?
• Czy źródła są skonfigurowane tak, aby rejestrować dane potrzebne do szczegółowej analizy?
• Czy wykorzystywane źródła uzupełniają się tak, aby najważniejsze warstwy środowiska nie pozostawały poza widocznością?
• Czy dane są przechowywane wystarczająco długo, aby można było wrócić do początku incydentu wykrytego z opóźnieniem?
• Czy organizacja kontroluje ciągłość napływu telemetrii i potrafi zauważyć, że któreś źródło przestało dostarczać dane?
• Czy alerty są analizowane w sposób ciągły przez zespół, który zna środowisko i potrafi odtworzyć przebieg incydentu?
• Czy po potwierdzeniu zagrożenia wiadomo, jakie działania należy podjąć, kto za nie odpowiada i jak szybko powinny zostać wykonane?

Odpowiedzi na te pytania pokazują, czy organizacja ma jedynie zestaw narzędzi bezpieczeństwa, czy rzeczywistą zdolność do obserwowania środowiska, analizowania incydentów i reagowania na zagrożenia.

Mniej czarnych dziur, szybsze decyzje

Skuteczna analiza zaczyna się znacznie wcześniej niż w chwili wygenerowania alertu. Wymaga świadomego zbierania danych, właściwej konfiguracji źródeł i stałej kontroli, czy telemetria nadal napływa. Dopiero na tej podstawie analityk może połączyć ślady z urządzeń, sieci, kont i usług w wiarygodny obraz incydentu.

SOC360 wykorzystuje telemetrię z uzupełniających się systemów, całodobową pracę analityków oraz mechanizmy pozwalające wykrywać również cichą utratę danych. Dzięki temu brak informacji nie zostaje automatycznie uznany za brak zagrożeń.

Sprawdź, jak SOC360 może pomóc Twojej organizacji ograniczyć luki w monitoringu i przekształcić dane z systemów bezpieczeństwa w skuteczną analizę oraz reakcję.