Czy do spełnienia wymogów ustawy o krajowym systemie cyberbezpieczeństwa (KSC / NIS2) potrzebne jest Security Operations Center (SOC)?

Wokół tego tematu narosło wiele nieporozumień. Część dostawców usług cyberbezpieczeństwa sugeruje, że każda organizacja objęta KSC musi zbudować pełne centrum operacji bezpieczeństwa działające 24/7. W praktyce przepisy są bardziej elastyczne. Ustawa nie wymaga wprost posiadania SOC, ale nakłada obowiązek zapewnienia ciągłego monitorowania oraz stosowania środków technicznych i organizacyjnych odpowiednich do poziomu ryzyka.

To oznacza, że dla jednych podmiotów właściwym rozwiązaniem może być zewnętrzne SOC lub usługa MDR, a dla innych wystarczające będzie dobrze zaprojektowane monitorowanie oparte na SIEM, alertach, dyżurach on-call i jasno opisanych procedurach reagowania. Kluczową kwestią nie jest więc samo posiadanie konkretnej usługi, lecz zdolność do wykrywania, analizy i obsługi zdarzeń bezpieczeństwa w sposób proporcjonalny do skali działalności, krytyczności systemów i potencjalnych skutków incydentu.

W artykule wyjaśniamy, czym różni się ciągłe monitorowanie wymagane przez KSC od pełnego SOC, kiedy SOC ma uzasadnienie, jakie są alternatywne modele oraz jak dobrać rozwiązanie do profilu ryzyka organizacji. Pokazujemy też, dlaczego droga do zgodności z dyrektywą NIS2 i KSC nie powinna zaczynać się od zakupu narzędzia, lecz od rzetelnej analizy ryzyka i określenia, które systemy rzeczywiście wymagają stałego monitorowania. 

Najważniejsze wnioski z artykułu

• KSC i NIS2 nie nakładają obowiązku posiadania Security Operations Center (SOC).
• Przepisy wymagają ciągłego monitorowania systemów informacyjnych, ale nie wskazują konkretnej technologii ani modelu organizacyjnego.
• Dobór sposobu monitorowania powinien wynikać z analizy ryzyka, wielkości organizacji i znaczenia chronionych systemów.
• Dla wielu organizacji własne SOC będzie rozwiązaniem nieproporcjonalnie drogim i nieuzasadnionym biznesowo.
• Ciągłe monitorowanie można realizować za pomocą różnych modeli, od podstawowego SIEM z dyżurami on-call po usługi MDR i pełne SOC.
• Ministerstwo Cyfryzacji wskazuje, że wymagania dotyczące monitorowania można spełnić również przy wykorzystaniu narzędzi SIEM, odpowiednich procedur i automatyzacji.
• Organizacje muszą być w stanie wykazać przed organem nadzorczym, że monitorowanie działa skutecznie i wspiera proces reagowania na incydenty.
• Kluczowe znaczenie mają procedury monitorowania, przechowywanie logów oraz gotowość do raportowania incydentów zgodnie z terminami określonymi w KSC.
• Własne SOC jest uzasadnione głównie dla organizacji o najwyższym profilu ryzyka, takich jak banki, operatorzy infrastruktury krytycznej czy duże podmioty kluczowe.
• Droga do zgodności z KSC powinna zaczynać się od szacowania ryzyka, a dopiero później od wyboru narzędzi i usług bezpieczeństwa.

Skąd wziął się mit obowiązkowego SOC?

Z oceny skutków regulacji wynika, że znowelizowane przepisy KSC obejmą swoim zasięgiem łącznie około 38 tysięcy podmiotów z 18 sektorów gospodarki. Z tego co najmniej 27,9 tysięcy stanowią podmioty z sektora publicznego, a pozostałe to podmioty działające m.in. w sektorach energetyki, transportu, bankowości, produkcji żywności i usług cyfrowych.

Wdrożenie tych przepisów wywołało na rynku niemała panikę. Zegar już tyka: do 3 października 2026 r. należy przeprowadzić samoidentyfikację i zgłosić się do rejestru, a do 3 kwietnia 2027 r. wymagane jest pełne wdrożenie środków zarządzania ryzykiem.

W tym napiętym okresie narosło wiele mitów napędzanych agresywnym marketingiem dostawców usług bezpieczeństwa. Jednym z najbardziej powielanych jest twierdzenie, jakoby dyrektywa NIS2 oraz znowelizowana KSC bezwzględnie wymuszały korzystanie z SOC.

SOC to wyspecjalizowana jednostka organizacyjna (lub usługa), której głównym zadaniem jest ciągłe monitorowanie, analizowanie i ochrona infrastruktury informatycznej przed cyberzagrożeniami. Zespół SOC przez całą dobę (w trybie ciągłym) obserwuje cyfrowe ekrany i szuka śladów podejrzanej aktywności. Gdy system podniesie alarm, eksperci SOC sprawdzają, czy jest on fałszywy, czy sygnalizuje realne zagrożenie.

Do kluczowych obszarów odpowiedzialności SOC należą:

• ciągłe monitorowanie (24/7) – agregacja i bieżąca obserwacja logów oraz zdarzeń pochodzących z całej infrastruktury IT: od serwerów i urządzeń sieciowych po aplikacje chmurowe i urządzenia końcowe użytkowników,
• wykrywanie i analiza zagrożeń – wykorzystanie systemów klasy SIEM (Security Information and Event Management) oraz algorytmów uczenia maszynowego do identyfikacji anomalii i niepożądanych zdarzeń,
• reagowanie na incydenty – podejmowanie natychmiastowych działań zaradczych po potwierdzeniu ataku, np. izolacja zainfekowanych stacji roboczych, zablokowanie złośliwego ruchu sieciowego oraz powstrzymanie eskalacji zagrożenia,
• działania proaktywne i prewencja – poszukiwanie ukrytych zagrożeń (ang. threat hunting) oraz zarządzanie podatnościami w systemach, co pozwala na uszczelnienie infrastruktury przed potencjalnymi wektorami ataku.

Wiele organizacji uważa, że bez dużego budżetu na SOC zgodność z przepisami KSC jest nieosiągalna. Jednak prawdziwy obraz regulacyjny, technologiczny i operacyjny jest znacznie bardziej zniuansowany – i zdecydowanie łaskawszy dla mniejszych oraz średnich organizacji, pod warunkiem że podejdą one do tematu analitycznie i strategicznie.

Zacznijmy od podstaw, nie od gotowych rozwiązań

W samej KSC słowo „SOC” nie pada ani razu. Pojawia się natomiast „monitorowanie” – i to w dwóch kluczowych miejscach:

„Monitorować w trybie ciągłym” nie oznacza SOC.

• w wykazie obowiązków podmiotów kluczowych lub podmiotów ważnych – jako „objęcie systemu informacyjnego wykorzystywanego do świadczenia usługi systemem monitorowania w trybie ciągłym” (art. 8 ust. 1 pkt 2 lit. g),
• załączniku nr 4 do ustawy – jako możliwy element systemu zarządzania bezpieczeństwem informacji w podmiotachm ważnych będącym podmiotami publicznymi: „monitorowanie dostępu do informacji oraz stanu działania systemów informacyjnych za pomocą dedykowanego oprogramowania wykorzystywanego przez pracowników albo korzystanie w tym zakresie z usług dostawcy usług zarządzanych w zakresie cyberbezpieczeństwa” (część II pkt 5).

Przepis art. 8 ust. 3 KSC wprowadza istotny wyjątek:

„Podmiot ważny będący podmiotem publicznym albo podmiotem, o którym mowa w art. 7 ust. 1 pkt 1–4 i 6–7 ustawy z dnia 20 lipca 2018 r. – Prawo o szkolnictwie wyższym i nauce, niebędącym organizacją badawczą w zakresie, w jakim realizuje zadania publiczne z wykorzystaniem systemów informacyjnych, nie stosuje przepisu ust. 1. Podmiot, o którym mowa w zdaniu pierwszym, opracowuje, wdraża, realizuje, monitoruje i utrzymuje w systemach informacyjnych kontrolowanych przez ten podmiot system zarządzania bezpieczeństwem informacji spełniający wymogi określone w załączniku nr 4 do ustawy”.

To oznacza, że:

• podmioty kluczowe – muszą stosować monitorowanie w trybie ciągłym,
• podmioty ważne będące instytucjami publicznymi lub uczelniami i instytutami – nie muszą,
• pozostałe podmioty ważne – muszą stosować monitorowanie w trybie ciągłym.

Przez „monitorowanie w trybie ciągłym” należy rozumieć nieprzerwane wykrywanie i obserwowanie zdarzeń w systemie. Przepis określa konkretny efekt, ale nie przesądza formy jego realizacji – ta wynika z obowiązku wdrożenia „odpowiednich i proporcjonalnych do oszacowanego ryzyka środków technicznych i organizacyjnych, uwzględniających najnowszy stan wiedzy, koszty wdrożenia, wielkość podmiotu, prawdopodobieństwo wystąpienia incydentów, narażenie podmiotu na ryzyka, skutki społeczne i gospodarcze” (art. 8 ust. 1 pkt 2 KSC).

Środki te muszą być:

• odpowiednie – dostosowane do zidentyfikowanych zagrożeń,
• proporcjonalne do oszacowanego ryzyka – uzasadnione poziomem skutków społecznych i gospodarczych oraz skutków dla podmiotu, a także wynikające z prawdopodobieństwa wystąpienia incydentu,
• uwzględniające najnowszy stan wiedzy, koszty rozwiązań i rozmiar podmiotu.

Prowadzi to do wniosku, że konkretne rozwiązanie musi mieć racjonalne, praktyczne uzasadnienie. Wiemy więc, że monitorowanie musi odbywać się w trybie ciągłym, ale to, jaką formę przyjmie, wyniknie z szacowania ryzyka.

Monitorować w trybie ciągłym, czyli… jak?

Zanim wybierzemy rozwiązanie, należy dokładniejprzyjrzeć się temu, co kryje się pod pojęciem monitorowania w trybie ciągłym.

Ministerstwo Cyfryzacji w dokumencie „Ustawa z dnia 5 lipca 2018 o krajowym systemie cyberbezpieczeństwa po nowelizacji. Pytania i odpowiedzi” wyjaśnia, jak rozumieć ciągłe monitorowanie:

„chodzi o to, aby zapewnić rozliczalność działań podejmowanych w systemie i analizować zaistniałe zdarzenia. Niekoniecznie trzeba w tym celu zatrudniać dodatkową osobę, można skorzystać z narzędzi open-source typu SIEM i ustawić adekwatne reguły. W szczególności należy monitorować zdarzenia, które mogą być przyczyną lub skutkiem incydentu. Monitorowanie dotyczy w szczególności ruchu z i do podmiotu, dostępu do systemu, kont z uprzywilejowanym dostępem, krytyczne pliki konfiguracyjne i kopii zapasowej, logi z narzędzi cyberbezpieczeństwa (np. antywirusów, anti-spyware), zdarzenia środowiskowe, które mogą mieć wpływ na funkcjonowanie infrastruktury systemu (zalanie, pożar itd.)” (s. 31).

Oznacza to, że

• monitorowanie musi działać w czasie rzeczywistym, przez 24 godziny na dobę, 7 dni w tygodniu – nie wystarczy codzienna kontrola o określonej porze,
• ciągłe monitorowanie musi obejmować systemy niezbędne do świadczenia usługi, a nie wszystkie systemy,
• zdarzenia z systemów muszą być na bieżąco analizowane – jedną z opcji jest kierowanie ich do rozwiązania SIEM.

Warto też pamiętać, że atakujący świadomie wybierają noce, weekendy i święta, ponieważ liczą na opóźnioną reakcję. Dlatego monitorowanie prowadzone tylko w godzinach pracy organizacji nie spełnia swojej funkcji wykrywania incydentów na czas.

Jak ciągłe monitorowanie może wyglądać w praktyce?

Zanim rozważymy opcje – warto wiedzieć, że podmioty objęte KSC podlegają nadzorowi.

• Podmioty kluczowe – nadzór ex ante (uprzedni): organ nadzorczy jest uprawniony do sprawdzania procedur, infrastruktury i dokumentacji w sposób proaktywny. Podmiot kluczowy musi na własny koszt przeprowadzać kompleksowy zewnętrzny audyt bezpieczeństwa systemu informacyjnego co najmniej raz na 3 lata. Ponadto właściwy organ może w każdej chwili zażądać dostępu do danych w ramach czynności kontrolnych lub nakazać przeprowadzenie skanów bezpieczeństwa i testów podatności.
• Podmioty ważne – nadzór ex post (następczy): odbywa się najczęściej w formie audytów doraźnych, z reguły po tym, gdy organizacja doświadczy poważnego incydentu lub gdy do organu wpłynie informacja o rażących naruszeniach. Podmioty ważne przeprowadzają audyt wyłącznie na żądanie organu właściwego do spraw cyberbezpieczeństwa.

Organ właściwy do spraw cyberbezpieczeństwa może prosić podmiot kluczowy lub podmiot ważny o przedstawienie dowodów wdrożenia systemu zarządzania bezpieczeństwem informacji. Mogą to być dokumenty, np. procedury, polityki, upoważnienia, zakresy obowiązków, ale również relacje personelu. Wymagane jest udowodnienie faktycznego stosowania przepisów KSC, a nie przedstawienie formalnie poprawnych dokumentów.

Dlatego podmioty muszą dysponować między innymi:

• polityką (lub procedurą) monitorowania – precyzyjnie definiującą, co jest monitorowane, dlaczego oraz kto i w jakich przedziałach czasowych odpowiada za reakcję na alerty i incydenty, a także określającą ramy funkcjonowania dyżurów lub współpracy z zewnętrznymi dostawcami,
• logami z systemów – przechowywanymi przez minimum 12 miesięcy (KSC nie definiuje tego okresu, lecz taka praktyka zapewnia historyczną ścieżkę audytu umożliwiającą badanie incydentów, podczas których tzw. dwell time – czas przebywania intruza w systemie – był stosunkowo długi).

Zdolność do ciągłego monitorowania jest integralnie powiązana z procedurą reagowania na incydenty oraz z rygorem raportowania incydentów, szczególnie tych sklasyfikowanych jako poważne:

• wczesne ostrzeżenie – w ciągu 24 godzin od wykrycia incydentu,
• zgłoszenie incydentu poważnego – w ciągu 72 godzin od wykrycia,
• sprawozdanie końcowe – w ciągu miesiąca od zgłoszenia incydentu.

Sprawozdanie końcowe to szczegółowy dokument analityczny zamykający obsługę incydentu, zawierający opis wektora ataku, analizę przyczyn (ang. root cause analysis) oraz zestawienie wszystkich skutków.

Przyjrzyjmy się SOC

Tradycyjne SOC wymaga fizycznej przestrzeni operacyjnej, systemów korelacji zdarzeń klasy SIEM oraz wyspecjalizowanego zespołu analityków, podzielonego na różne linie wsparcia, realizującego w udokumentowany sposób procesy reagowania na incydenty w trybie ciągłym, tj. 24 godziny na dobę.

• Tier 1 – całodobowy monitoring konsoli SIEM, wstępna weryfikacja napływających zdarzeń i alertów oraz odsiewanie fałszywych alarmów.
• Tier 2 – pogłębiona analiza incydentów eskalowanych przez tier 1 oraz podejmowanie aktywnych działań naprawczych i powstrzymujących atak.
• Tier 3 – najbardziej doświadczeni eksperci zajmujący się zaawansowaną analizą i proaktywnym poszukiwaniem zagrożeń, prowadzący analizę śledczą, opracowujący nowe reguły detekcji.

Posiadanie własnego SOC daje organizacji pełną autonomię i dużą elastyczność. Wewnętrzne zespoły doskonale znają specyfikę biznesową i technologiczną swojej firmy. Taka wiedza pozwala im na bezbłędne i błyskawiczne rozróżnianie fałszywych alarmów (ang. false positives) oraz zjawisk charakterystycznych dla danej branży od realnych ataków. Analitycy ściśle współpracują z działem IT, co gwarantuje najszybszy możliwy czas izolacji krytycznych incydentów i blokowania zaatakowanych segmentów infrastruktury. Można powiedzieć, że własne SOC to swego rodzaju „final boss” monitorowania zdarzeń.

SOC ma nie tylko zalety, lecz także poważne ograniczenia. Jednym z nich jest wysoki stały koszt operacyjny: aby zapewnić ciągłą pracę przez całą dobę, z uwzględnieniem dyżurów, świąt, rotacji kadr i urlopów, trzeba zatrudnić minimum 5–6 analityków na sam pierwszy poziom (tier 1). Oprócz tego trzeba jeszcze uwzględnić wysoki popyt na specjalistów (i ich niedobór na rynku pracy), stale rosnące wynagrodzenia w sektorze cyberbezpieczeństwa oraz koszty licencji komercyjnych systemów klasy enterprise, wycenianych w modelu wolumetrycznym (zależnym od indeksowanych danych GB/dzień) lub w zależności od liczby zdarzeń na sekundę (EPS – Events Per Second).

Dojrzałe SOC coraz częściej korzystają z systemów klasy SOAR (ang. Security Orchestration, Automation and Response), które automatyzują powtarzalne zadania tier 1, takie jak izolacja zainfekowanego hosta, blokowanie złośliwego adresu IP czy tworzenie zgłoszeń incydentów. SOAR nie zastępuje analityków, ale pozwala zmniejszyć ich liczbę i skrócić czas reakcji. Jest to jednak rozwiązanie dla organizacji z ugruntowanymi procesami bezpieczeństwa. Dla większości podmiotów objętych KSC pozostaje poza zakresem rozważań.

Własne SOC to zatem opcja raczej dla największych graczy. KSC pozwala jednak dobrać formę monitorowania w trybie ciągłym odpowiednio do poziomu ryzyka. Poniżej przedstawiamy dostępne alternatywy.

Model 1: monitorowanie podstawowe

Monitoring w trybie 8/5 z asystą typu on-call – polega na połączeniu pełnej, całodobowej automatyzacji wykrywania zagrożeń z elastycznym czasem reakcji personelu. Systemy bezpieczeństwa pracują bez przerwy (24/7), natomiast analiza zdarzeń przez człowieka jest prowadzona w sposób ciągły w godzinach pracy (8/5), a po ich zakończeniu – w trybie alarmowym (reaktywnym).

Przykładowe wdrożenie:

• Wazuh – aktywny system klasy SIEM/XDR, odpowiadający za bieżącą analizę logów w poszukiwaniu wzorców ataków, monitorowanie integralności plików systemowych oraz wykrywanie podatności w oprogramowaniu.
• Serwer Syslog – repozytorium surowych danych, gwarantujące, że logi z urządzeń sieciowych (firewalle, switche) trafiają do wydzielonej, bezpiecznej lokalizacji. Choć Wazuh może samodzielnie zbierać logi, oddzielny serwer Syslog daje dodatkowe korzyści:
  • w przypadku włamania do panelu Wazuha i skasowania alertów na serwerze Syslog pozostają fizyczne dowody ataku,
  • przeciążenie Wazuha nie powoduje utraty logów – lekki serwer Syslog będzie wciąż je zapisywał,
  • logi w Syslogu są nieprzetworzone, co może zwiększać ich wartość dowodową.
• Obsługa alertów:
  • w godzinach pracy – przez wyznaczonego administratora IT,
  • po godzinach – przez administratora pełniącego dyżur, któremu system SIEM przesyła powiadomienia o najwyższym priorytecie (np. przez SMS lub komunikator).
• Koszty: licencje – 0 zł (open source), wdrożenie – koszt pracy administratora, utrzymanie – koszt dyżurów on-call.
• Podziały ról:
  • tier 1 – automatyka SIEM oraz administratorzy w godzinach pracy,
  • tier 2 – administrator pełniący dyżur on-call lub starszy administrator IT,
  • tier 3 – w razie bardzo poważnego incydentu; w małych organizacjach raczej nie występuje.

Monitorowanie w tym modelu można rozszerzać o dodatkowe komponenty, np.:

• NDR (Network Detection and Response) – wysokiej klasy rozwiązanie oparte na uczeniu maszynowym i sztucznej inteligencji, pozwalające wykryć intruza dobrze ukrywającego swoją obecność, której reguły korelacji SIEM nie są w stanie zidentyfikować,
• Honeypot – najtańszy wykrywacz włamań, który udaje łatwy cel (np. serwer z otwartym dostępem do bazy danych), dzięki czemu każdy ruch w stronę takiej pułapki jest jednoznacznym sygnałem działania intruza,
• agenci EDR (Endpoint Detection and Response) – oprogramowanie instalowane bezpośrednio na systemach końcowych, które przesyła do serwera dane o zdarzeniach, weryfikuje sumy kontrolne plików, wykrywa podatności w zainstalowanych pakietach oraz wykonuje automatyczne skrypty blokujące zagrożenia w odpowiedzi na konkretne alerty,
• moduł FIM (File Integrity Monitoring) – narzędzie monitorujące istotne pliki i foldery, które w przypadku wykrycia jakiejkolwiek zmiany natychmiast generuje alarm w Wazuhu.

Model 2: własny SIEM – zewnętrzne SOC

W takim modelu narzędzia do ciągłego monitorowania są zarządzane przez organizację, a bieżące monitorowanie i analiza incydentów są zlecane zewnętrznemu dostawcy. Jeśli dostawca potwierdzi prawdziwy incydent, powiadomi organizację lub administratora pełniącego dyżur on-call. Monitorowanie oraz analiza przez człowieka odbywają się w trybie ciągłym 24/7, natomiast reakcja następuje w trybie 8/5, a po zakończeniu pracy – w trybie on-call.

Model ten wybierają firmy, które chcą uniknąć uzależnienia od dostawcy (ang. vendor lock-in). Jeśli zewnętrzne SOC podniesie ceny lub obniży jakość usług, organizacja po prostu zmienia dostawcę – analitycy nowej firmy logują się do jej systemu SIEM.

Przykładowe wdrożenie:

• Systemy SIEM, np. Microsoft Sentinel, Splunk, Rapid7 InsightIDR.
• Obsługa alertów – 24/7 przez SOC dostawcy.
• Koszty:
  • SIEM – zależnie od rozwiązania i sposobu wdrożenia,
  • SOC – zależnie od skali i liczby zdarzeń oraz nakładu pracy zespołu; w przypadku małej skali można rozważać koszt rzędu 5–10 tys. zł netto miesięcznie.
• Podziały ról:
  • tier 1 – dostawca SOC,
  • tier 2 – hybrydowy: dostawca SOC (eksperci od incydentów) oraz organizacja (administratorzy systemów),
  • tier 3 – dostawca SOC.

Model 3: MDR (Managed Detection and Response)

Organizacja instaluje u siebie lekkie kolektory danych (np. log forwardery) oraz agenty (EDR/XDR). Dane są przesyłane do systemu SIEM dostawcy. System ten, zazwyczaj działający w chmurze (SaaS), jest przez niego utrzymywany, aktualizowany i wyposażony w autorskie reguły detekcji.

Dostawca dostarcza własne, sprawdzone narzędzia, bo tylko wtedy może zagwarantować, że wykryje i zablokuje atak w określonym czasie (np. 15 minut).

Przykładowe wdrożenie:

• Konfiguracja logów po stronie organizacji – logi trafiają do odpowiednich kolektorów („zbieraczy”) i są przesyłane do systemu SIEM dostarczanego i utrzymywanego przez dostawcę.
• Obsługa alertów – 24/7 przez SOC dostawcy.
• Koszty:
  • opłata subskrypcyjna – najczęściej stały koszt miesięczny „za urządzenie” lub „za użytkownika”,
  • brak kosztów utrzymania – organizacja nie płaci za serwery pod SIEM, prąd, storage logów ani za szkolenia analityków,
  • przewidywalność – koszt licencji SIEM jest wliczony w cenę usługi SOC.
• Podziały ról
  • tier 1 – dostawca SOC,
  • tier 2 – hybrydowy: dostawca SOC (eksperci od incydentów wykonują analizę techniczną i mogą podjąć określone działania, takie jak izolacja laptopa przez agenta EDR) oraz organizacja (administratorzy systemów mogą np. przywrócić serwer z backupu),
  • tier 3 – ekspertyza powłamaniowa, informatyka śledcza i wsparcie w raportowaniu incydentu do organów nadzorczych (np. CSIRT).

Model 4: własne SOC – pełna autonomia

Organizacja posiada własną infrastrukturę (SIEM/XDR), własne procedury i przede wszystkim – własny zespół ekspertów pracujący w trybie zmianowym. To model dla podmiotów o najwyższym profilu ryzyka: banków, infrastruktury krytycznej, dużych podmiotów kluczowych objętych KSC.

• Infrastruktura – SIEM klasy enterprise (np. Microsoft Sentinel, Splunk, FortiSIEM) zainstalowany lokalnie lub w prywatnej chmurze, z pełną kontrolą nad architekturą, logami i regułami korelacji.
• Tryb pracy – rzeczywiste monitorowanie 24/7/365: zespół reaguje natychmiast, bez pośrednictwa zewnętrznych firm i bez opóźnień wynikających z komunikacji między różnymi organizacjami.
• Obsługa alertów – wszystkie poziomy kompetencyjne (tier 1, 2 i 3) znajdują się wewnątrz organizacji.
• Koszty (wysoka bariera wejścia):
  • wynagrodzenia – utrzymanie zespołu 6–10 specjalistów cyberbezpieczeństwa oraz ciągłe inwestowanie w certyfikację i wiedzę zespołu,
  • licencje SIEM klasy enterprise – wysoki koszt przy dużej skali logów.
• Podziały ról:
  • tier 1 (analitycy SOC) – minimum 5–6 osób pracujących w systemie zmianowym, odpowiedzialnych za ciągłe monitorowanie konsoli i natychmiastową reakcję na każdy alert,
  • tier 2 (specjaliści IR) – doświadczeni eksperci od reagowania na incydenty (Incident Response), zajmujący się głęboką analizą (np. badaniem malware) i koordynacją blokowania zagrożeń,
  • tier 3 (threat hunterzy/inżynierowie) – eksperci odpowiedzialni za proaktywne szukanie luk, pisanie własnych reguł detekcji i zaawansowaną architekturę systemu.

Porównanie modeli monitorowania

Poniższa tabela podsumowuje opisane modele i ułatwia dobór rozwiązania do profilu oraz skali organizacji.

Co dla kogo

Wybór modelu zależy od analizy ryzyka: jakie są skutki incydentu, kogo obejmują i jak szybko należy zareagować. Rozważmy dwa skrajne przypadki:

Podmiot z sektora gospodarowania odpadami

• Profil ryzyka – najważniejsze zagrożenie to paraliż logistyczny i operacyjny: cyberatak może unieruchomić systemy planowania tras lub sterowanie automatyką w sortowni. Skutki (nieodebrane odpady, ryzyko pożaru lub skażenia) stają się krytyczne dopiero po kilkunastu godzinach lub dniach. Istnieje zatem okno czasowe na reakcję, zanim problem przerodzi się w zagrożenie epidemiologiczne.
• Rekomendowane rozwiązanie – model 1 (SIEM 8/5 + on-call): automatyczny monitoring działa nieprzerwanie, a w razie wykrycia anomalii w nocy administrator IT jest powiadamiany podczas dyżuru. Pozwala to na podjęcie działań naprawczych przed poranną zmianą, bez konieczności utrzymywania kosztownej obsady nocnej.

Narodowy Bank Polski

• Profil ryzyka – najwyższy możliwy: dotyczy bezpieczeństwa i stabilności finansowej państwa. Ataki mogą mieć różne podłoże – polityczne (APT) lub terrorystyczne. Skutki udanego włamania mogą być katastrofalne dla całej gospodarki, dlatego czas reakcji musi być liczony w sekundach. Ze względu na tajemnicę państwową i krytyczność operacji dane nie powinny być analizowane przez podmioty trzecie w modelach współdzielonych.
• Rekomendowane rozwiązanie – model 4 (własne SOC – pełna autonomia): własny zespół analityków pracujący w trybie zmianowym na miejscu. Systemy klasy enterprise umożliwiają natychmiastową izolację zagrożeń i pełną kontrolę nad przepływem informacji, co jest jedynym akceptowalnym standardem dla instytucji o znaczeniu strategicznym.

Wnioski

Wokół dyrektywy NIS2 i nowelizacji ustawy o KSC narosło wiele mitów – w tym ten najkosztowniejszy: że zgodność z przepisami wymaga zbudowania własnego Security Operations Center. Ustawa takiego wymogu nie nakłada. Nakłada natomiast obowiązek monitorowania w trybie ciągłym. Przy czym sposób jego realizacji musi być proporcjonalny do profilu ryzyka danego podmiotu – nie do katalogu usług zewnętrznego dostawcy.

Droga do zgodności z KSC nie zaczyna się od zakupu systemu SIEM ani od podpisania kontraktu z dostawcą MDR. Zaczyna się od rzetelnej analizy ryzyka, która wskaże systemy wymagające monitorowania i określi potrzebny poziom ich ochrony. Dopiero na tej podstawie warto dobierać narzędzia i modele operacyjne.

Trzy pytania, które warto zadać na początku:

• które systemy są kluczowe dla świadczonej usługi i muszą być objęte monitoringiem ciągłym?
• jakiego poziomu reagowania – automatycznego czy z udziałem człowieka – wymaga nasz profil ryzyka?
• czy organizacja dysponuje własnymi zasobami do analizy zdarzeń, czy może powinna skorzystać z zewnętrznego wsparcia?

Odpowiedzi na te pytania – poparte dokumentacją polityki monitorowania i szacowaniem ryzyka – są właściwym punktem startowym dla każdej organizacji objętej KSC. Przepisy dają swobodę w wyborze narzędzi, wymagają jednak, by wybór ten był świadomy i uzasadniony.

FAQ – najczęściej zadawane pytania

Czy ustawa KSC wymaga wdrożenia SOC?

Nie. Ustawa o krajowym systemie cyberbezpieczeństwa nie zawiera obowiązku posiadania Security Operations Center. Wymaga natomiast wdrożenia ciągłego monitorowania systemów informacyjnych oraz środków bezpieczeństwa adekwatnych do poziomu ryzyka.

Czym różni się ciągłe monitorowanie od SOC?

Ciągłe monitorowanie to wymagany przez przepisy efekt, polegający na bieżącym wykrywaniu i analizowaniu zdarzeń bezpieczeństwa. SOC jest jednym ze sposobów realizacji tego celu, ale nie jedynym.

Czy mała lub średnia firma musi budować własne SOC?

W większości przypadków nie. Dla wielu organizacji wystarczające będzie wdrożenie systemu SIEM, odpowiednich procedur oraz modelu dyżurów on-call lub współpracy z zewnętrznym dostawcą usług bezpieczeństwa.

Jakie są alternatywy dla własnego SOC?

Najczęściej stosowane alternatywy to:

• monitorowanie oparte na SIEM i dyżurach administratorów,
• własny SIEM obsługiwany przez zewnętrzne SOC,
• usługa MDR (Managed Detection and Response),
• model hybrydowy łączący zasoby własne i zewnętrzne.

Czy monitorowanie musi działać 24/7?

Tak. KSC wymaga monitorowania w trybie ciągłym. Oznacza to zdolność do wykrywania zdarzeń przez całą dobę, także w nocy, weekendy i święta.

Jak dobrać model monitorowania do wymagań KSC?

Punktem wyjścia powinna być analiza ryzyka uwzględniająca krytyczność systemów, potencjalne skutki incydentu oraz wymagany czas reakcji. Dopiero na tej podstawie należy wybierać narzędzia i model organizacyjny.

Czy podmiot objęty KSC musi korzystać z usług zewnętrznego SOC?

Nie. Organizacja może samodzielnie realizować monitorowanie, jeśli jest w stanie zapewnić odpowiedni poziom wykrywania i reagowania na incydenty oraz udokumentować spełnienie wymagań ustawy.

Co będzie sprawdzane podczas kontroli lub audytu?

Organ nadzorczy może zweryfikować m.in. polityki monitorowania, procedury reagowania na incydenty, przechowywane logi, dokumentację systemu zarządzania bezpieczeństwem informacji oraz rzeczywiste funkcjonowanie wdrożonych procesów.