SOC (Security Operations Center)

SOC (Security Operations Center) to zespół wraz z narzędziami i procedurami, który w sposób ciągły monitoruje bezpieczeństwo systemów organizacji, wykrywa incydenty i uruchamia reakcję. NIST opisuje SOC jako centralny punkt operacji bezpieczeństwa i obrony sieci organizacji, którego celem jest stała obrona i monitorowanie jej systemów i sieci ^[1]. SOC odpowiada też za terminowe wykrywanie, analizę i reagowanie na incydenty ^[1]. W polskich tekstach używa się też opisowej nazwy „centrum monitorowania bezpieczeństwa” ^[3].

Jak działa

Według NIST organizacja obsadza SOC analitykami bezpieczeństwa, specjalistami od reagowania na incydenty i inżynierami bezpieczeństwa systemów ^[1]. Zespół łączy środki techniczne, zarządcze i operacyjne, w tym narzędzia do monitorowania, skanowania i analizy śledczej. Służą one do monitorowania, łączenia, korelowania i analizowania danych o zagrożeniach i zdarzeniach z wielu źródeł, a także do reagowania na nie ^[1]. Źródłami są między innymi zabezpieczenia brzegowe, urządzenia sieciowe i agenci na stacjach końcowych ^[1].

W praktyce dane te trafiają do systemu SIEM, który zbiera logi i generuje alerty. Analityk ocenia każdy alert w procesie triażu (triage) i odsiewa fałszywe alarmy (false positive). Potwierdzone zdarzenie przechodzi do analizy i reagowania na incydenty. Wnioski wracają do reguł wykrywania, co opisuje dziedzina detection engineering. Cykl pracy pokazuje schemat poniżej.

RYS. 1Cykl pracy SOC

Oprócz obsługi alertów SOC prowadzi aktywne poszukiwanie śladów włamania, którego nie wychwyciły automatyczne reguły. Niebezpiecznik opisuje to jako threat hunting (polowanie na zagrożenia), czyli właśnie to, czym zajmują się pracownicy SOC-ów ^[5]. Ten sam tekst wymienia narzędzia używane do tej pracy, między innymi Splunk, Wazuh i Elastic ^[5].

Składniki

Na stacjach końcowych działają narzędzia klasy EDR i XDR, powtarzalne kroki reakcji automatyzuje SOAR, a procedury dla typowych incydentów spisuje się jako playbooki.

SOC można zbudować na kilka sposobów. NIST zauważa, że większe organizacje tworzą własny, wydzielony SOC, a mniejsze korzystają z podmiotów zewnętrznych, które zapewniają taką zdolność ^[1]. Usługę zewnętrzną z wykrywaniem i reakcją oferuje model MDR.

SOC a CSIRT

SOC i CSIRT często się przenikają, ale nie są tym samym. SOC skupia się na ciągłym monitorowaniu i wykrywaniu, CSIRT na obsłudze zgłoszonych incydentów w obrębie określonej społeczności. CERT Polska w rekomendacjach dla zespołów CSIRT z sierpnia 2025 roku zaznacza, że wskazówki można odpowiednio stosować do innych zespołów bezpieczeństwa komputerowego, takich jak CERT, SOC czy ISAC ^[4].

Dyrektywa NIS2 przewiduje współpracę obu typów zespołów. Do zadań unijnej sieci CSIRT należy między innymi współpraca i wymiana informacji z regionalnymi i unijnymi centrami monitorowania bezpieczeństwa (SOC), by poprawić wspólną świadomość sytuacyjną ^[3].

NIST w wytycznych SP 800-61 Rev. 3 z kwietnia 2025 roku wpisuje reagowanie na incydenty w całość zarządzania ryzykiem według NIST Cybersecurity Framework 2.0 ^[2]. Chodzi o przygotowanie na incydenty, ograniczanie ich liczby i skutków oraz sprawniejsze wykrywanie i odtwarzanie ^[2]. SOC realizuje przede wszystkim część wykrywania i pierwszej reakcji. Wersja trzecia zastąpiła poprzednią, SP 800-61 Rev. 2 z sierpnia 2012 roku ^[2].

W WordPressie

Pojedyncza strona na WordPressie rzadko ma własny SOC. Może jednak dostarczać dane do SOC firmy albo dostawcy usług. Najcenniejsze są zdarzenia związane z logowaniem i zmianami w panelu.

WordPress udostępnia akcję wp_login_failed, wywoływaną po nieudanym logowaniu ^[6]. Istnieje od wersji 2.5.0; od 4.5.0 przekazuje także adres e-mail, jeśli nim próbowano się zalogować, a od 5.4.0 obiekt WP_Error ze szczegółami błędu ^[6]. Wtyczka lub kod w motywie potomnym może na tej podstawie zapisywać próby do logu wysyłanego do SIEM.

add_action( 'wp_login_failed', function ( $username, $error ) {
    error_log( 'login_failed user=' . sanitize_user( $username ) );
}, 10, 2 );

Z perspektywy SOC strona WordPress jest tylko jednym z wielu źródeł. Logi serwera WWW, logi PHP i zdarzenia z panelu trzeba sprowadzić do wspólnego formatu i wspólnego zegara, aby dało się je zestawić z danymi z sieci i stacji końcowych. Bez tego analityk nie ustali, czy nieudane logowania i późniejsza zmiana pliku to jeden incydent, czy dwa niezależne zdarzenia.

Seria takich zdarzeń z jednego adresu wskazuje na atak siłowy (brute-force), a z wielu adresów i dla wielu kont — na credential stuffing. SOC łączy je z innymi sygnałami, takimi jak nieautoryzowane konto administratora albo alert z monitorowania integralności plików.

Znaczenie i wyzwania

Wartość SOC zależy od jakości danych i od tego, czy alerty ktoś rzeczywiście ogląda. NIST podkreśla, że SOC daje całościową świadomość sytuacyjną, która pozwala ocenić stan bezpieczeństwa systemu i organizacji ^[1].

• Nadmiar alertów. Zbyt wiele powiadomień prowadzi do zmęczenia alertami (alert fatigue) i przeoczeń.
• Luki w danych. Czego nie ma w logach, tego SOC nie zobaczy; dlatego ważna jest retencja logów.
• Mierzenie skuteczności. Typowe miary to MTTD i MTTR, czyli średni czas wykrycia i reakcji.
• Wiedza o przeciwniku. Reguły wykrywania korzystają z threat intelligence i wskaźników kompromitacji (IoC).