W rozmowach z klientami wciąż widzimy bardzo duże zainteresowanie tematem Security Operations Center (SOC) w kontekście dyrektywy NIS 2. Wynika to przede wszystkim z faktu, że projekt ustawy o Krajowym Systemie Cyberbezpieczeństwa (UoKSC), implementującej dyrektywę NIS 2 w Polsce, nie wskazuje wprost, jaki model lub zakres działania SOC zapewnia zgodność z wymaganiami NIS 2. Specyfika aktów prawnych powoduje, że regulacje pozostawiają szerokie pole do interpretacji, które bez znajomości intencji ustawodawcy oraz odpowiedniej wiedzy prawnej i technologicznej trudno jednoznacznie ocenić.
Monitoring w trybie ciągłym, budowa lub outsourcing komórki bezpieczeństwa, różne terminy raportowania incydentów – wszystko to rodzi pytania zarówno po stronie organizacji, jak i zarządów. W tym artykule wyjaśniamy, co jest faktycznie wymagane, aby przejść audyt zgodności z NIS 2 w obszarze zarządzania incydentami oraz jakie elementy SOC dają realną wartość w zakresie bezpieczeństwa, a nie tylko formalną zgodność.
Monitoring w trybie ciągłym według NIS 2 i UoKSC
Pojęcie „monitoringu w trybie ciągłym” pozostawia pewne pole do interpretacji, jednak w praktyce jest ono tożsame z monitoringiem 24/7. Oznacza to konieczność posiadania wewnętrznego zespołu SOC lub współpracy z zewnętrznym dostawcą, który przez całą dobę, siedem dni w tygodniu monitoruje infrastrukturę organizacji.
Monitoring musi obejmować kluczowe elementy infrastruktury mające realny wpływ na bezpieczeństwo i ciągłość działania organizacji. Częściowy monitoring, np. wyłącznie endpointów lub jedynie środowiska OT, nie zapewnia zgodności z NIS 2. Co istotne, monitoring nie polega wyłącznie na wdrożeniu narzędzia – takiego jak SIEM – ale na istnieniu zespołu analityków, który aktywnie korzysta z technologii, analizuje zdarzenia i reaguje na zagrożenia.
W tym miejscu warto podkreślić, że SOC odpowiada za detekcję, analizę, eskalację, ale decyzjami biznesowymi jak uruchomienie procedur kryzysowych, zgłaszanie do organów czy komunikację z partnerami/kontrahentami zajmuje się już bezpośrednio klient (chyba, że umowa przewiduje inaczej). Tego typu szczegóły należy ustalić na wstępie, ponieważ w przypadku realnego ataku brak jasnych ustaleń będzie prowadził do nieścisłości, opóźnień czy chaosu.
Poza obowiązkiem monitoringu w trybie ciągłym NIS 2 nakłada na organizacje obowiązek raportowania incydentów cyberbezpieczeństwa. W praktyce oznacza to konieczność nie tylko reagowania na zagrożenia, lecz także ich dokumentowania i zgłaszania w odpowiedniej formie, we właściwym czasie i do właściwych organów. Co więcej, organizacje powinny brać pod uwagę również incydenty i podatności w całym swoim łańcuchu dostaw – incydenty u dostawców mogą podlegać raportowaniu, jeśli mają istotny wpływ na funkcjonowanie organizacji.
NIS 2 i UoKSC- terminy i obowiązki raportowania
Zrozumienie ram czasowych oraz typów raportów przewidzianych w NIS 2 jest podstawą do osiągnięcia zgodności z NIS 2. Na obecnym etapie projekt UoKSC wskazuje jasno określone obowiązki raportowe, które rozpoczynają się od tzw. wczesnego ostrzeżenia. Organizacja ma maksymalnie 24 godziny od wykrycia incydentu poważnego na dokonanie jego wstępnej oceny, klasyfikację incydentu na podstawie określonych progów oraz zgłoszenie zdarzenia do właściwego CSIRT sektorowego. Wczesne ostrzeżenie musi wskazać, czy poważny incydent został przypuszczalnie wywołany działaniem bezprawnym, czy działaniem w złym zamiarze oraz czy mógł wywrzeć wpływ transgraniczny. UoKSC definiuje, jakie CSIRT sektorowe oraz organy są dedykowane dla konkretnych sektorów.
Kolejnym etapem jest tzw. zgłoszenie incydentu, czyli przesłanie w ciągu 72 godzin od wykrycia incydentu poważnego raportu, który powinien zawierać aktualizację informacji z wczesnego ostrzeżenia oraz wstępnej oceny poważnego incydentu, jego ciężaru, wpływu na organizację oraz wskaźników kompromitacji. W toku obsługi incydentu właściwy CSIRT może również zażądać raportów tymczasowych, obejmujących bieżący status działań naprawczych, sposób współpracy z CSIRT (NASK, GOV, MON lub sektorowym) oraz przekazywanie niezbędnych danych, w tym danych osobowych.
Proces raportowania zamyka sprawozdanie końcowe, które musi zostać złożone nie później niż w ciągu miesiąca od zgłoszenia incydentu poważnego i powinien zawierać analizę przyczyn zdarzenia, jego skutki, zastosowane i wdrażane środki zaradcze ograniczające ryzyko oraz ewentualny wpływ transgraniczny.
Jakie technologie są wymagane przez NIS 2 i UoKSC?
UoKSC nie wskazuje konkretnych technologii poza wykorzystaniem kryptografii, szyfrowania oraz uwierzytelniania wieloskładnikowego lub ciągłego. Warto jednak jasno wyjaśnić, jaką rolę w SOC pełnią poszczególne rozwiązania. Jeśli mówimy o monitoringu w trybie ciągłym i raportowaniu, punktem wyjścia są systemy klasy SIEM. To właśnie SIEM został zaprojektowany do agregacji zdarzeń z całego środowiska – endpointów, sieci, serwerów, chmury czy aplikacji.
W praktyce sam SIEM nie zawsze wystarcza. Po wykryciu zagrożenia często konieczna jest bardziej szczegółowa analiza, np. na poziomie endpointu. W takich przypadkach kluczowe stają się technologie klasy EDR, które dostarczają szczegółowej telemetrii i umożliwiają głębsze zrozumienie zdarzenia. W miarę wzrostu skali i złożoności środowiska SIEM coraz częściej musi być uzupełniany również o rozwiązania klasy NDR do analizy ruchu sieciowego.
Wybór technologii powinien być poprzedzony analizą potrzeb. Zazwyczaj po przekroczeniu pewnej skali i poziomu złożoności środowiska niezbędne staje się połączenie SIEM, EDR i NDR, natomiast punktem wyjścia powinien być SIEM.
Zewnętrzny SOC a NIS 2 – jak wybrać dostawcę?
Większość organizacji dążących do zgodności z NIS 2 w obszarze zarządzania incydentami decyduje się na outsourcing SOC. Wynika to z wysokich kosztów budowy wewnętrznego SOC (często 4–5 razy wyższych niż koszt usługi SOC), niedoboru ekspertów na rynku oraz dużej rotacji pracowników w zespołach SOC.
Spełnienie obowiązków wynikających z NIS 2 w praktyce wymaga współpracy z dojrzałym SOC, który zapewnia nie tylko wykrywanie incydentów, ale również pełną transparentność i dostęp do danych. Skuteczny SOC musi dysponować możliwie najszerszą telemetrią, w tym dostępem do surowych logów z systemów, sieci i aplikacji, co pozwala na rzetelną analizę i weryfikację zdarzeń.
Równie istotna jest inżynieria detekcji – domyślne reguły bezpieczeństwa rzadko odpowiadają specyfice konkretnego środowiska, dlatego realna wartość SOC wynika z ciągłego dostosowywania mechanizmów detekcji do organizacji, jej branży oraz wykorzystywanych technologii.
W kontekście wymagań NIS 2 niezbędna jest również zaawansowana analiza zagrożeń oparta o Cyber Threat Intelligence. Dostawca SOC powinien korzystać z komercyjnych źródeł CTI oraz posiadać ekspertów zdolnych do analizy zagrożeń charakterystycznych dla danego sektora.
Skuteczność działań SOC musi być przy tym mierzalna – organizacja powinna wymagać jasno zdefiniowanych wskaźników SLA i KPI, takich jak MTTD, MTTR czy czas eskalacji, które odzwierciedlają realną zdolność do reagowania na incydenty.
Całość powinna być uzupełniona o odpowiednie certyfikacje i zgodność z uznanymi modelami oraz standardami, takimi jak Trusted Introducer, ISO 27001, ISO 22301 czy SIM3, a także o potwierdzone kompetencje zespołu analityków w postaci certyfikatów branżowych.
W praktyce warto żeby organizacje decydowały się na współpracę z dostawcami, którzy łączą szerokie kompetencje technologiczne z doświadczeniem regulacyjnym. Takie podejście stosuje m.in. Trecom – partner realizujący wdrożenia SOC zgodne z NIS 2 w organizacjach wymagających ciągłego monitorowania bezpieczeństwa oraz automatyzacji reakcji. Praktyczne know-how zdobywane przy projektach, w tym dedykowany zespół konsultingowy dla analiz ryzyka, wdrażania polityk tematycznych, usług CISOaaS czy szkoleń pozwala zbudować spójny ekosystem bezpieczeństwa dopasowany do realnych potrzeb biznesowych oraz regulacyjnych.
Zarządzanie podatnościami w SOC
NIS 2 nie ogranicza się wyłącznie do reagowania na incydenty, lecz wprost odnosi się do zarządzania ryzykiem i podatnościami. Kluczowe znaczenie ma tu integracja SOC z procesem zarządzania podatnościami. Dojrzały SOC koreluje zdarzenia bezpieczeństwa z aktywnymi podatnościami (CVE) występującymi w środowisku organizacji.
Wykorzystanie danych z narzędzi klasy Vulnerability Management pozwala ocenić, czy wykryta aktywność dotyczy rzeczywiście podatnego systemu oraz jaki jest realny poziom ryzyka. Dzięki temu alerty są priorytetyzowane w oparciu o faktyczną ekspozycję, a nie wyłącznie o sygnatury czy ogólną krytyczność podatności.
Testowanie SOC i gotowości organizacji
NIS 2 bardzo mocno akcentuje zasadę ciągłego doskonalenia zdolności cyberbezpieczeństwa. Oznacza to, że samo posiadanie SOC i procedur reagowania nie jest wystarczające – muszą one być regularnie testowane. Dojrzały dostawca SOC powinien oferować cykliczne table-top exercises, testy procedur raportowych oraz wsparcie w działaniach typu purple teaming, łączących symulowany atak, detekcję i reakcję.
Całość powinna kończyć się raportami typu lessons learned, które stanowią podstawę do dalszej optymalizacji procesów. To właśnie te działania realnie skracają MTTD i MTTR, zamiast jedynie deklarować gotowość w dokumentacji.
Dyrektywa NIS 2 nie narzuca jednego, uniwersalnego modelu SOC, lecz wymaga realnej zdolności do ciągłego monitorowania, skutecznego zarządzania incydentami i terminowego raportowania. Oznacza to, że skuteczny SOC musi być dopasowany do skali, złożoności i profilu ryzyka organizacji, a nie jedynie spełniać formalne wymagania regulacyjne. Właściwie zaprojektowany model SOC łączy zgodność z NIS 2 z faktycznym podniesieniem poziomu cyberbezpieczeństwa i odporności operacyjnej.
O autorze
Przemysław Szalwa – analityk SOC z ponad czteroletnim doświadczeniem w zespołach operacyjnych i technicznych. Na co dzień wspiera organizacje w obszarze monitoringu bezpieczeństwa, zarządzania incydentami oraz inżynierii detekcji, uczestnicząc w projektach SOC realizowanych m.in. dla sektora publicznego i enterprise. Specjalizuje się w praktycznym wdrażaniu procesów SOC, automatyzacji reakcji oraz Threat Huntingu.