Co dokładnie otrzymuje klient w usłudze SOC? Zakres, odpowiedzialność i przykładowy przebieg obsługi incydentu w Security Operations Center
Zakres usługi SOC może obejmować całodobowy monitoring bezpieczeństwa, weryfikację alertów, analizę incydentów, ocenę ryzyka oraz przygotowywanie rekomendacji. W zależności od uzgodnionego modelu współpracy zespół SOC może również wykonywać określone działania techniczne.
„Monitoring 24/7” to zdanie, które można zrozumieć na kilka różnych sposobów. Dla jednych oznacza system wysyłający automatyczne powiadomienia o alertach z konsoli. Dla innych – pełny proces, w którym każde zdarzenie przechodzi przez analizę, dochodzenie i przygotowanie konkretnej rekomendacji, zanim trafi do klienta.
Różnica rzadko jest widoczna na etapie podpisywania umowy. Ujawnia się dopiero w dniu, w którym coś faktycznie się wydarzy, wtedy jest już za późno, żeby ją zmieniać. Artykuł pokazuje, co dokładnie powinien obejmować zakres usługi SOC, krok po kroku, na przykładzie typowego przebiegu obsługi incydentu.
Jak wygląda obsługa incydentu w SOC? Przykładowy scenariusz
Proces obsługi incydentów jest skomplikowany. By nie pozostał abstrakcją, poniższe osiem etapów prześledzimy na przykładzie poglądowym – złożeniu typowych wzorców obserwowanych w środowiskach korporacyjnych, nie opisie konkretnego, pojedynczego przypadku.
O 2:47 w nocy odnotowano logowanie przez RDP do serwera plików – z konta administracyjnego, z adresu IP, który wcześniej nie występował w historii tego konta, i o porze wykraczającej poza typowe okno aktywności tego użytkownika.
1. Wykrycie zdarzenia
Systemy monitorujące objęte usługą SOC (źródła telemetrii z urządzeń końcowych, logi uwierzytelniania, dane sieciowe) rejestrują zdarzenie w momencie jego wystąpienia. W naszym scenariuszu: nietypowe logowanie RDP generuje alert na podstawie odpowiednio skonfigurowanych reguł detekcji, a czas wykrycia zależy od dostępności i przetwarzania danych.
To etap technologiczny, ponieważ system rejestruje fakt, nie ocenia jeszcze jego znaczenia. Monitoring bezpieczeństwa 24/7 zaczyna się właśnie tutaj (telemetria napływa bez przerwy, niezależnie od pory dnia).
2. Analiza alertu przez SOC L1
Alert trafia do analityka pierwszej linii (L1), którego zadaniem jest wstępna ocena:
Czy zdarzenie odpowiada znanemu, wcześniej udokumentowanemu wyjątkowi, czy wymaga dalszej analizy?
W naszym przykładzie L1 sprawdza podstawowe parametry – konto, urządzenie, adres źródłowy, godzinę i konfrontuje je z listą znanych, zaakceptowanych wzorców aktywności w środowisku klienta.
Zdarzenie nie pasuje do żadnego udokumentowanego wyjątku. Konto nigdy wcześniej nie logowało się z tej lokalizacji, a organizacja nie ma zaplanowanych prac serwisowych w tym oknie czasowym. Alert nie zostaje zamknięty jako fałszywy alarm, zamiast tego trafia do analizy pogłębionej.
3. Pogłębiona analiza incydentu przez SOC L2
Analityk drugiej linii (L2) prowadzi dochodzenie wykraczające poza wstępną weryfikację. Sprawdza:
- pełną historię aktywności konta w dłuższym oknie czasowym
- profil typowego zachowania powiązanego urządzenia
- geolokalizację adresu źródłowego
oraz to, czy podobne odstępstwa występowały wcześniej w innych częściach środowiska.
W naszym scenariuszu L2 ustala, że konto administracyjne w ciągu ostatnich kilku miesięcy logowało się wyłącznie z dwóch znanych, wewnętrznych adresów IP (nigdy z adresu widocznego w tym zdarzeniu). Adres źródłowy odpowiada zakresowi przypisanemu do dostawcy usług hostingowych, co samo w sobie nie przesądza o niczym, ale zawęża dochodzenie.
4. Korelacja zdarzeń bezpieczeństwa
To etap, który odróżnia analizę SOC od reagowania na pojedynczy alert. Analityk sprawdza, czy zdarzenie współwystępuje z innymi sygnałami z tego samego okresu – nieudanymi próbami logowania poprzedzającymi udane uwierzytelnienie, aktywnością na innych urządzeniach powiązanych z tym samym kontem, czy próbami dostępu do zasobów wykraczających poza typowy zakres działań tego konta.
W naszym przykładzie korelacja ujawnia serię kilkunastu nieudanych prób logowania na to samo konto w ciągu godziny poprzedzającej udane uwierzytelnienie – wzorzec zgodny z próbą odgadnięcia lub przetestowania skradzionych danych logowania, a nie z pojedynczą pomyłką użytkownika.
5. Przygotowanie kontekstu i ocena ryzyka
Zebrane informacje składają się w spójny obraz zdarzenia:
- co się wydarzyło,
- w jakiej kolejności,
- dlaczego odbiega to od normalnego wzorca,
- jaki jest wstępny poziom ryzyka.
To etap, na którym pojedyncze, techniczne fakty (adres IP, godzina, liczba prób logowania) zamieniają się w narrację zrozumiałą dla osoby podejmującej decyzję po stronie klienta, nawet jeśli nie zna ona szczegółów technicznych dochodzenia.
6. Rekomendacje dla klienta
To moment, w którym często ujawnia się rzeczywista różnica między usługami SOC. Zespół nie przekazuje klientowi wyłącznie informacji „wykryto podejrzane zdarzenie”. Przekazuje opis przebiegu incydentu, ocenę jego zakresu i konkretną, uzasadnioną rekomendację działania.
W naszym scenariuszu rekomendacja brzmi: zawiesić dostępność konta administracyjnego do czasu wyjaśnienia, wymusić reset hasła i weryfikację MFA, sprawdzić, do jakich zasobów na serwerze plików faktycznie uzyskano dostęp podczas tej sesji. Rekomendacja jest konkretna i możliwa do wykonania od razu.
7. Eskalacja incydentu bezpieczeństwa
Sposób przekazania informacji zależy od powagi sytuacji i wcześniej uzgodnionych zasad. Zdarzenie o takim charakterze (możliwe wskazanie na przejęte konto administracyjne) kwalifikuje się do eskalacji telefonicznej do wcześniej wyznaczonej osoby kontaktowej, z równoległym udokumentowaniem incydentu w formie zgłoszenia lub ticketu zawierającego pełny opis, chronologię i rekomendację na piśmie.
Zdarzenia o niższej istotności mogą być przekazywane kanałem mailowym lub przez system ticketowym, bez konieczności natychmiastowego kontaktu telefonicznego.
8. Reakcja i działania po stronie klienta
Zakres usługi SOC kończy się w miejscu, gdzie zaczyna się decyzja i działanie po stronie organizacji. Chyba że zakres reakcji technicznej został wcześniej uzgodniony inaczej. W naszym przykładzie to zespół klienta podejmuje ostateczną decyzję o zawieszeniu konta (lub w uzgodnionym wcześniej zakresie robi to bezpośrednio zespół SOC), koordynuje dalsze kroki z działem HR czy bezpieczeństwa fizycznego, jeśli okoliczności tego wymagają, oraz weryfikuje faktyczny zakres dostępu do danych podczas podejrzanej sesji.
Rozróżnienie co wykonuje SOC, a co pozostaje po stronie klienta powinno być ustalone przed uruchomieniem usługi, nie odkrywane w trakcie pierwszego realnego zdarzenia.
Surowy alert a pełna analiza SOC - co otrzymuje klient?
Warto zestawić ten proces z tym, jak wyglądałaby obsługa tego samego zdarzenia w modelu ograniczonym do przekazywania powiadomień. Poznaj różnicę między wykryciem alertu, a jego obsługą.
Model ograniczony do alertów: klient otrzymuje wiadomość „wykryto logowanie RDP z nieznanego adresu IP na koncie administracyjnym”. Bez dalszego kontekstu, bez informacji o próbach logowania poprzedzających zdarzenie, bez oceny zakresu potencjalnego dostępu do danych. Ocena sytuacji i decyzja o dalszych krokach spoczywa w całości na zespole klienta, który musi samodzielnie odtworzyć kontekst, mając do dyspozycji tylko surowe dane z konsoli.
Obsługa SOC: klient otrzymuje gotowy, uporządkowany obraz sytuacji:
- chronologię zdarzenia,
- wynik korelacji z innymi sygnałami,
- ocenę ryzyka,
- konkretną rekomendację działania.
Decyzja pozostaje po stronie klienta, ale nie musi on samodzielnie przeprowadzać dochodzenia, żeby tę decyzję podjąć świadomie.
Za co odpowiada SOC, a za co klient?
To dwa różne obszary działań, które powinny opowiednio się zazębiać, aby poprawnie reagować na incydenty bezpieczeństwa w organizacji.
| Obszar | SOC | Klient |
|---|---|---|
| Monitoring | Analizowanie danych z uzgodnionych źródeł | Zapewnienie dostępu do źródeł |
| Analiza incydentu | Kwalifikacja, korelacja i dochodzenie | Dostarczenie wiedzy o środowisku |
| Rekomendacje | Ocena ryzyka i wskazanie działań | Podjęcie niezbędnych decyzji |
| Reakcja techniczna | W ramach przyznawanych uprawnień | Pozostałe działania operacyjne |
| Działania naprawcze | Wsparcie zgodnie z zawartą umową | Koordynacja i realizacja poza zakresem SOC |
* Przykładowy podział odpowiedzialności. Rzeczywisty zakres powinien wynikać z umowy, SLA i uzgodnionych procedur.
Co warto ustalić przed uruchomieniem usługi SOC?
Wartość usługi SOC widać wtedy, gdy zakres i podział odpowiedzialności są jasno ustalone. Najlepiej, jeśli ustalenia zakończą się przed pierwszym incydentem. Pytania, które warto zadać dostawcy SOC.
Warto, żeby ta ustalona wcześniej mapa obejmowała: które źródła danych są objęte monitoringiem, jakie kryteria decydują o eskalacji telefonicznej, a jakie o zgłoszeniu mailowym lub ticketowym, jakie działania techniczne mogą zostać wykonane przez zespół SOC bez dodatkowej zgody, a które zawsze wymagają decyzji po stronie klienta, oraz kto ostatecznie odpowiada za wykonanie działań naprawczych – zamknięcie luki, przywrócenie systemów, dalsze dochodzenie powłamaniowe, jeśli okaże się potrzebne.
Dobrze zaprojektowana usługa SOC nie zastępuje zespołu IT klienta ani jego wiedzy o środowisku. Dostarcza ciągłość obserwacji, analizę i rekomendację tam, gdzie samodzielne utrzymanie takiej zdolności przez całą dobę wymagałoby zasobów nieproporcjonalnych do potrzeb wielu organizacji.
Zakres usługi SOC nie powinien być czymś, co poznajesz tak naprawdę dopiero w trakcie pierwszego prawdziwego incydentu. Pytanie, które warto zadać przy ocenie dowolnej oferty SOC, brzmi:
Czy to, co otrzymam w momencie zdarzenia, będzie surowym alertem, czy gotowym do podjęcia decyzji opisem sytuacji z konkretną rekomendacją?
Chcesz zadbać o cyberbezpieczeństwo?
Skontaktuj się z nami!
Zostaw dane – oddzwonimy
Nasz specjalista odezwie się do Ciebie najpóźniej kolejnego dnia roboczego. Nie musisz wypełniać pola wiadomości, ale krótka informacja o interesującym Cię temacie rozmowy będzie dla nas cenną wskazówką.
