Kto patrzy na alerty po osiemnastej: Security Operations Center (SOC) w średniej firmie

Security Operations Center (SOC) to nie kolejne pudełko dołożone do firewalla, lecz funkcja organizacyjna: ktoś czyta zdarzenia spływające z systemów, odróżnia szum od ataku i podejmuje decyzję o reakcji, gdy napastnik jest już w środku. Antywirus zatrzymuje to, co rozpoznaje. SOC zajmuje się tym, czego nikt jeszcze nie zablokował.

Dlaczego antywirus i firewall nie zastępują Security Operations Center (SOC)

Antywirus i firewall należą do warstwy prewencyjnej: rozstrzygają pojedyncze zdarzenie w ułamku sekundy, według reguły albo sygnatury. Security Operations Center (SOC) należy do warstwy detekcyjnej: składa wiele drobnych, osobno niewinnych zdarzeń w jedną historię i odpowiada na pytanie, czy w sieci trwa właśnie atak. To dwie różne funkcje, nie dwa poziomy tego samego produktu.

Różnica ujawnia się w momencie, w którym napastnik przestaje używać złośliwego pliku. Logowanie prawidłowym hasłem z nietypowego kraju, utworzenie konta administracyjnego, wyłączenie usługi, nocny transfer dużej porcji danych – każde z tych zdarzeń z osobna mieści się w normie technicznej i nie wywoła blokady. Dopiero zestawione w kolejności opisują włamanie.

Typowa średnia firma ma te dane: firewall zapisuje ruch, kontroler domeny logowania, stacje końcowe uruchomione procesy. Problem nie polega na braku informacji, lecz na braku adresata:

• od 8:00 do 17:00 alerty widzi administrator, w przerwach między zgłoszeniami użytkowników,

• po 17:00 alerty trafiają na skrzynkę, którą ktoś otworzy nazajutrz,

• w weekend i w święta nie ma nikogo, więc przerwa w obserwacji obejmuje kilka kolejnych dni,

• po urlopie jedynej osoby znającej konsolę nikt nie wie, które reguły zostały wyciszone.

Ta asymetria nie wynika z zaniedbania, lecz z arytmetyki jednoosobowego dyżuru. Czas między wejściem do sieci a uruchomieniem szkodliwego działania to okno, w którym reakcja jest jeszcze możliwa przed wystąpieniem szkody.

Co robi Security Operations Center (SOC) w czasie trwającego ataku

Security Operations Center (SOC) wykonuje trzy czynności, które muszą następować jedna po drugiej: wykrywa odstępstwo, klasyfikuje je i decyduje o działaniu. Drugim krokiem jest triage, czyli ocena i uszeregowanie zdarzeń według wagi. Dopiero po nim zapada rozstrzygnięcie: obserwować, odciąć maszynę albo zablokować konto.

Ta kolejność pokazuje zarządowi, czym SOC nie jest. SOC nie jest ubezpieczeniem ani obietnicą, że atak się nie wydarzy. Jest skróceniem drogi od pierwszego śladu do decyzji. Wykrycie włamania w toku to zresztą inna czynność niż późniejsze przywrócenie danych – rozstrzygają się w innym momencie i opierają na innych kompetencjach.

Praca detekcyjna opiera się na wiedzy o tym, jak napastnicy faktycznie postępują. Publicznie dostępną, uporządkowaną bazą takiej wiedzy jest MITRE ATT&CK – katalog taktyk i technik obserwowanych w rzeczywistych atakach, od uzyskania pierwszego dostępu, przez podnoszenie uprawnień, aż po wyprowadzanie danych. Dla dyrektora IT jest to przydatne narzędzie zakupowe: zamiast pytać dostawcę o liczbę obsługiwanych źródeł logów, można zapytać, które techniki z tego katalogu są pokryte regułami detekcji.

W pracy SOC rozdziela się bieżącą obserwację konsoli od pogłębionej analizy incydentu i od badań powłamaniowych. Dostawcy nazywają to liniami wsparcia. Dla firmy ważniejsze od nazewnictwa jest jedno: która z tych czynności jest dostępna w nocy, a która dopiero w dzień roboczy.

SIEM, EDR i SOAR: warstwa narzędziowa Security Operations Center (SOC)

Narzędzia Security Operations Center (SOC) dzielą się na trzy role, które w rozmowach handlowych bywają mieszane. SIEM zbiera i koreluje logi z wielu źródeł. EDR obserwuje zachowanie procesów na stacjach i serwerach. SOAR automatyzuje powtarzalne kroki reakcji. Żadne z nich nie zastępuje pozostałych i żadne nie zastępuje analityka.

Rozróżnienie ma następstwo kosztowe. Kto kupuje tylko agregację logów, dostaje archiwum zdarzeń i obowiązek ich czytania. Kto kupuje tylko ochronę stacji końcowych, nie zobaczy ataku na poziomie tożsamości i uprawnień. Zakres źródeł podłączonych do korelacji jest istotniejszy niż marka konsoli.

Na etapie wdrożenia dobiera się zarówno klasy narzędzi, jak i dokumentację procedur. W opisie usługi ITCenter zakres tego etapu obejmuje dobór i konfigurację rozwiązań klasy SIEM, DLP oraz EDR, MDR i XDR, a także archiwizację logów i procedury reagowania w razie incydentu. Jest to zakres jednej oferty, nie standard rynkowy, więc taką listę warto traktować jako przedmiot uzgodnień, a nie jako gotowy pakiet licencji.

Fałszywe alarmy i zmęczenie alertami: realne ograniczenie Security Operations Center (SOC)

Największym praktycznym problemem Security Operations Center (SOC) nie jest brak alertów, lecz ich nadmiar. False positive, czyli alarm wskazujący zagrożenie tam, gdzie go nie ma, jest w detekcji nieunikniony: reguły działają na prawdopodobieństwie, a nie na pewności. Skutkiem ubocznym jest zjawisko określane jako zmęczenie alertami – stan, w którym zespół przestaje reagować, bo reagował już sto razy bez powodu.

Nowo uruchomiona korelacja generuje początkowo dużo zgłoszeń, bo nie zna specyfiki środowiska. Jeśli nikt nie dostraja reguł, administrator zaczyna wyciszać całe kategorie zdarzeń. Po kilku miesiącach konsola jest spokojna, ale spokój ten nie wynika z bezpieczeństwa, tylko z wygaszonych reguł.

Dojrzałość detekcji mierzy się więc nie liczbą alertów, lecz udziałem alertów zasadnych i tym, czy ktoś systematycznie ten udział poprawia. Na spotkaniu technicznym warto zapytać, kto i jak często przegląda reguły, które nie dały ani jednego trafnego zgłoszenia. Brak odpowiedzi jest sygnałem ostrzegawczym niezależnie od tego, jak rozbudowana jest platforma.

MTTD i MTTR: jak mierzyć skuteczność Security Operations Center (SOC)

Skuteczność Security Operations Center (SOC) daje się opisać dwiema wielkościami. MTTD (mean time to detect) to średni czas od wystąpienia zdarzenia do jego wykrycia. MTTR (mean time to respond) to średni czas od wykrycia do podjęcia działania ograniczającego skutki. Obie liczy się z własnych incydentów i obie mają sens tylko mierzone konsekwentnie przez dłuższy okres.

Dla zarządu te wskaźniki są wygodniejsze niż katalog funkcji, bo opisują skutek, nie wyposażenie. Firma, która wykrywa incydent po tygodniu, ma problem organizacyjny, nawet jeśli dysponuje nowoczesną platformą. Firma, która wykrywa po dwóch godzinach, ale decyzję o odcięciu zasobu podejmuje po dwóch dniach, ma problem decyzyjny, nie techniczny.

Pomiar wiąże się także z obowiązkami zewnętrznymi. Dyrektywa NIS2 wprowadza do porządku prawnego Unii Europejskiej wymóg zgłaszania poważnych incydentów organom krajowym, przy czym zakres objętych nim podmiotów i szczegóły procedury zależą od sektora oraz od przepisów wdrażających. Niezależnie od tego, czy firma podlega tym regulacjom, w Polsce działa CERT Polska – zespół reagowania na incydenty komputerowe funkcjonujący w strukturze NASK, który przyjmuje zgłoszenia i publikuje ostrzeżenia o aktualnych kampaniach. Odrębną podstawą porządkowania tych procesów jest norma ISO/IEC 27001, opisująca wymagania dla systemu zarządzania bezpieczeństwem informacji, w tym dla postępowania z incydentami.

Własny czy zewnętrzny Security Operations Center (SOC): co rozstrzygnąć przed wyborem

Decyzja o modelu Security Operations Center (SOC) sprowadza się do pytania o obsadę, nie o licencje. Detekcja prowadzona poza godzinami pracy wymaga kilku osób na zmianach, a nie jednej z nadgodzinami. To zwykle moment, w którym średnia firma stwierdza, że własny zespół całodobowy jest poza jej zasięgiem, i rozważa wariant usługowy.

Najczęściej spotykane są trzy układy. Pierwszy to wsparcie istniejącego zespołu wewnętrznego okresową weryfikacją skuteczności wdrożonych narzędzi. Drugi to pełne przeniesienie funkcji do dostawcy, określane skrótem SOCaaS. Trzeci to gotowe pakiety o ustalonym z góry zakresie, adresowane do mniejszej skali. Przy porównywaniu ofert rozstrzyga nie nazwa pakietu, lecz to, które z trzech czynności detekcyjnych są w nim faktycznie wykonywane i kto je wykonuje.

Niezależnie od wybranego układu kilka rozstrzygnięć pozostaje po stronie firmy i nie da się ich kupić. Trzeba wskazać osobę uprawnioną do zgody na odcięcie systemu produkcyjnego w środku zmiany, ustalić listę zasobów krytycznych, bo bez niej każdy alert ma tę samą wagę, oraz zdecydować, kto rozmawia z pracownikami i kontrahentami w trakcie incydentu. Dopiero gdy te trzy sprawy są przesądzone, zlecone na zewnątrz monitorowanie bezpieczeństwa w modelu SOC przekłada się na szybszą reakcję, a nie na dłuższą ścieżkę akceptacji. Kolejność ma znaczenie: uruchomienie usługi przed tymi ustaleniami przenosi na dostawcę detekcję, ale nie decyzję.

Security Operations Center (SOC) w średniej firmie: pytania zadawane przed decyzją

Po jakim czasie od podpisania umowy detekcja faktycznie coś wykrywa? Pierwsze reguły działają, gdy spłyną logi z kluczowych źródeł. Użyteczna detekcja wymaga jednak przejścia przez pełny cykl pracy firmy, z zamknięciem miesiąca i nocnymi zadaniami wsadowymi, żeby odróżnić zachowanie nietypowe od sezonowego. Pierwsze tygodnie służą nauce środowiska.

Co musi być gotowe po stronie firmy, żeby zacząć? Trzy rzeczy: inwentaryzacja systemów ze wskazaniem krytycznych; dostęp do logów, co w starszych systemach bywa pracą samą w sobie; oraz pisemna zgoda na działania wykonywane bez pytania. Bez tego trzeciego punktu detekcja działa, a reakcja czeka na telefon.

Czy obecny antywirus i firewall trafiają do wymiany? Zwykle nie. Warstwa prewencyjna zostaje tam, gdzie jest, a detekcja ją nadbudowuje, korzystając z generowanych przez nią zdarzeń. Do sprawdzenia jest, czy posiadane rozwiązania wysyłają logi w formacie przyjmowanym przez korelację i czy licencja tego nie ogranicza.

Kogo z firmy angażuje praca z detekcją na co dzień? Mniej osób, niż się zakłada, ale konkretnie wskazanych: administratora znającego środowisko, osobę decyzyjną dostępną poza godzinami pracy oraz kogoś, kto potwierdzi, czy nietypowa operacja była planowana. Najczęstszym powodem opóźnionej reakcji jest brak osoby decyzyjnej.

Jak wygląda detekcja przy kilku oddziałach i pracy zdalnej? Rozproszenie zmienia nie tyle narzędzia, co punkt odniesienia. Komputer łączący się z sieci domowej nie jest anomalią, więc reguły oparte na lokalizacji tracą sens, a ciężar przenosi się na tożsamość i zachowanie konta. Uprawnienia trzeba uporządkować przed uruchomieniem detekcji, nie po.

Czego taka usługa nie zrobi za zarząd? Nie przejmie odpowiedzialności za ryzyko i nie rozstrzygnie, które systemy firma jest gotowa zatrzymać, żeby ograniczyć szkodę. Nie zastąpi decyzji o budżecie na usunięcie ujawnionych podatności. Monitorowanie pokazuje stan faktyczny; co z nim zrobić, pozostaje decyzją właścicielską.

Artykuł sponsorowany