SOC po wdrożeniu. Jak wygląda codzienna współpraca z Security Operations Center?
Usługa SOC została uruchomiona. Systemy przesyłają logi, analitycy monitorują infrastrukturę przez całą dobę, a administrator może wreszcie odetchnąć? Niekoniecznie. W tym miejscu rozpoczyna się etap, od którego w dużej mierze zależy skuteczność całej usługi.
Jak dokładnie wygląda współpraca z Security Operations Center?
Dlaczego wykrycie podejrzanego zachowania nie zawsze oznacza incydent i co dzieje się, gdy analityk SOC potrzebuje informacji, których nie znajdzie w systemie monitorowania?
O tych zagadnieniach w trzecim odcinku podcastu Perceptus rozmawiają Grzegorz Gąsiewski, Dyrektor SOC, oraz Łukasz Zajdel, Dyrektor Sprzedaży. Zestawiają perspektywę rozmów z klientami z praktyką codziennego monitorowania i reagowania na zagrożenia.
Zakup usługi SOC to dopiero początek współpracy
Decyzję o rozpoczęciu współpracy z zewnętrznym SOC poprzedzają zazwyczaj rozmowy o zakresie usługi, możliwościach technicznych, czasie reakcji i odpowiedzialności dostawcy. Klient przedstawia swoje oczekiwania, a dostawca określa, jakie działania będzie realizować – rozpoczyna się wdrożenie.
Na tym etapie pojawia się pierwsze wyzwanie: oczekiwania ustalone podczas rozmów handlowych trzeba przełożyć na realne procesy operacyjne.
Podłączenie źródeł logów, ustalenie zasad komunikacji, przekazanie informacji o infrastrukturze czy określenie sposobu eskalacji zdarzeń wymaga współpracy obu stron.
Nie zawsze jednak przebiega ona tak sprawnie, jak zakładano.
Z perspektywy SOC ma to swoje konsekwencje. Brak dostępu do odpowiednich danych oznacza ograniczoną widoczność zdarzeń. Z kolei niepełna wiedza o infrastrukturze utrudnia ocenę, czy zarejestrowana aktywność jest prawidłowa, czy może stanowić zagrożenie.
Uruchomienie usługi to początek procesu, w którym dostawca stopniowo poznaje środowisko klienta, a organizacja uczy się współpracować z zespołem monitorującym.
System wykrył podejrzaną aktywność. Czy to już incydent?
Wyobraźmy sobie sytuację, w której pracownik przesyła dużą ilość danych do chmury.
System monitorowania wykrywa nietypowy transfer i generuje alert. Czy mamy do czynienia z próbą kradzieży informacji?
Niekoniecznie.
Może to być pracownik działu marketingu, który przesyła materiały wideo do współpracującej agencji lub administrator wykonujący zaplanowany backup. Nie zmienia to faktu, że podobna aktywność może oznaczać, że atakujący próbuje wyprowadzić dane z organizacji.
W takich sytuacjach widać różnicę między automatycznym wykrywaniem zdarzeń a ich analizą. Alert informuje, że wystąpiła aktywność spełniająca określone kryteria, ale nie zawsze pozwala jednoznacznie ocenić jej przyczynę.
Analityk SOC brać pod uwagę kontekst. Sprawdzić źródło i cel komunikacji, powiązane zdarzenia, zachowanie użytkownika oraz to, czy podobna aktywność występowała wcześniej. Czasami odpowiedź znajduje się w dostępnych logach. Innym razem konieczne jest skontaktowanie się z administratorem organizacji.
SOC widzi zdarzenia techniczne, ale nie zawsze zna ich biznesowy kontekst. A bez niego nawet poprawnie wykryta anomalia może zostać błędnie zinterpretowana.
Dlaczego SOC nie przekazuje klientowi wszystkich alertów?
W dobrze monitorowanej infrastrukturze liczba generowanych zdarzeń może być bardzo duża. Nie każde wymaga jednak interwencji administratora. Uwypakla się różnica między systemem wysyłającym automatyczne powiadomienia a usługą, w której analitycy nieustannie weryfikują i klasyfikują zdarzenia.
Analitycy SOC weryfikują alerty, łączą powiązane informacje i odrzucają zdarzenia, które okazują się fałszywymi alarmami, czyli tzw. false positives.
Administrator nie musi samodzielnie sprawdzać każdej wygenerowanej detekcji. Nie oznacza to jednak, że fałszywe alarmy można ignorować.
Jak wyjaśnia Grzegorz, wielokrotne generowanie nieuzasadnionych alertów przez tę samą regułę może wskazywać na konieczność zmiany jej konfiguracji.
Zbyt czuła reguła może generować wiele nieistotnych zgłoszeń, powodując szum informacyjny. Zbyt restrykcyjne wyjątki mogą natomiast ograniczać wykrywanie rzeczywistych zagrożeń.
Co więcej, reguła, która przez kilka miesięcy działała prawidłowo, może zacząć generować niepotrzebne alerty po aktualizacji systemu operacyjnego, zmianie konfiguracji lub wdrożeniu nowego oprogramowania.
Dlatego dostrajanie mechanizmów detekcji jest stałym elementem pracy SOC, a nie wyłącznie czynnością wykonywaną podczas pierwszej konfiguracji.
SOC a MDR - czym różnią się w praktyce?
Choć obie usługi służą wykrywaniu cyberzagrożeń i wspierają bezpieczeństwo organizacji, różnią się zakresem monitorowania oraz możliwościami reagowania. W trzecim odcinku podcastu Grzegorz Gąsiewski wyjaśnia te różnice na przykładzie usług realizowanych w Perceptus.
| Obszar | SOC (Security Operations Center) | MDR (Managed Detection and Response) |
|---|---|---|
| Zakres monitorowania | Szerszy obraz infrastruktury IT, obejmujący wiele systemów i źródeł danych. | Skupienie przede wszystkim na urządzeniach końcowych i serwerach objętych ochroną EDR/XDR. |
| Źródła informacji | Logi z firewalli, serwerów, urządzeń sieciowych, Active Directory, usług chmurowych i systemów bezpieczeństwa. | Telemetria i detekcje pochodzące głównie z systemów EDR/XDR. |
| Analiza zagrożeń | Korelacja zdarzeń z różnych systemów, identyfikacja anomalii i ocena potencjalnych incydentów. | Szczegółowa analiza podejrzanych zachowań i procesów na monitorowanych urządzeniach. |
| Reagowanie | W omawianym modelu przede wszystkim wykrywanie, analiza i informowanie administratora o zagrożeniach wymagających reakcji. | Możliwość podjęcia działań bezpośrednio na urządzeniu, np. izolacji hosta lub zatrzymania podejrzanego procesu. |
| Główna korzyść | Szersza widoczność zdarzeń w infrastrukturze organizacji. | Głębsza analiza aktywności urządzeń i możliwość szybkiej reakcji na zagrożenie. |
SOC i MDR nie muszą być rozwiązaniami konkurencyjnymi. Mogą się wzajemnie uzupełniać, łącząc szerszy monitoring infrastruktury ze szczegółową analizą i reagowaniem na poziomie urządzeń końcowych.
Co organizacja powinna przygotować przed uruchomieniem usługi SOC?
W rozmowie pojawia się jeszcze jeden problem: niepełna wiedza o własnej infrastrukturze.
Zdarza się, że analitycy wykrywają komunikację między urządzeniami, a administrator nie potrafi jednoznacznie wskazać, do czego służy dany host.
W dużych, rozproszonych środowiskach, szczególnie przy niewielkich zespołach IT, nie jest to sytuacja niemożliwa. Stanowi jednak poważne utrudnienie podczas analizy zagrożeń.
Aby SOC mógł skutecznie wykonywać swoją pracę, organizacja powinna zadbać przede wszystkim o:
Aktualną inwentaryzację zasobów – szczególnie systemów krytycznych, ich przeznaczenia i wzajemnych zależności.
Informacje o normalnym działaniu infrastruktury – np. godzinach wykonywania backupów, planowanych pracach administracyjnych i nietypowych procesach biznesowych.
Sprawne kanały komunikacji i eskalacji – z określeniem osób kontaktowych, zasad dyżurów oraz sposobu reagowania na zgłoszenia.
Widoczność zdarzeń – upewnienie się, że systemy objęte monitoringiem rzeczywiście przesyłają logi potrzebne do analizy.
Skuteczna usługa SOC wymaga współpracy po obu stronach
Wdrożenie usługi Security Operations Center nie rozwiązuje automatycznie wszystkich problemów bezpieczeństwa organizacji.
SOC może zapewniać całodobową analizę zdarzeń, wykrywać podejrzane zachowania i ograniczać liczbę alertów wymagających zaangażowania administratora. Nie oznacza to jednak, że zna wszystkie procesy biznesowe klienta, ma nieograniczone uprawnienia w jego infrastrukturze albo może podejmować każdą decyzję samodzielnie.
Potrzebuje aktualnych informacji, właściwie skonfigurowanych źródeł danych i kontaktu z osobami, które znają środowisko organizacji.
I być może właśnie to najlepiej podsumowuje codzienną pracę z zewnętrznym SOC.
Bezpieczeństwo nie jest efektem jednostronnego przekazania odpowiedzialności dostawcy. Jest rezultatem współpracy, w której obie strony wiedzą, czego od siebie oczekują, jakie działania mogą wykonać i jak reagować, kiedy pojawia się rzeczywiste zagrożenie.
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ą.
