Mapowanie NIS2 w praktyce: jak Wazuh i Zabbix pokrywają wymagania art. 21

Znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa (UKSC) obowiązuje w Polsce od 2 kwietnia 2026 r., a wraz z nim NIS 2 – dyrektywa, której Polska nie zdążyła transponować w terminie UE (17.10.2024 r.), a której konsekwencje będą dotyczyły bezpośrednio zarządów. Do końca października 2026 r. istnieje obowiązek samoidentyfikacji i rejestracji, a do 2 kwietnia 2027 r. – pełne wdrożenie Systemu Zarządzania Bezpieczeństwem Informacji (SZBI) zgodnie z art. 8 UKSC. Tak w skrócie można podsumować kluczowe informacje jakie wymagania będzie trzeba spełnić.

Jednak ten artykuł przedstawiam jako praktyczny przewodnik. Jak – korzystając z dwóch darmowych, otwartoźródłowych narzędzi, jakimi są: Wazuh i Zabbix – spełnić wymagania techniczne art. 21 ust. 2 NIS 2, aby zarząd miał czym się osłonić przed kontrolą, a Security Operations Center (SOC) miał czym żyć przez najbliższe dwa lata. Bez lukru: pokazuję, co te narzędzia realnie załatwią, a czego nie załatwią, nawet jeśli ktoś Wam tak obiecywał na dziwnych konferencjach z napisem *NIS 2*…

NIS 2 i UKSC – co jest realnie egzekwowalne

Pomijam całą historię NIS 1 → NIS 2 i dwa lata dramatu legislacyjnego. To, co musicie mieć w głowie, można zmieścić w pięciu punktach:

• Kto podlega – podmioty kluczowe (duże firmy z sektorów takich jak: energetyka, transport, bankowość, zdrowie, infrastruktura zasobów wodnych, infrastruktura cyfrowa, administracja publiczna, kosmos) i podmioty ważne (średnie, m.in. usługi pocztowe, odpady, chemia, żywność, produkcja, usługi cyfrowe, nauka). Obowiązki techniczne są te same – różni się tylko nadzór (ex-ante vs ex-post) i kary.
• Kary – do 10 mln euro lub 2% obrotu (podmioty kluczowe), do 7 mln euro lub 1,4% obrotu (podmioty ważne). Plus osobista odpowiedzialność kierownika podmiotu, co stanowi novum, które zarządy zaczęły już zauważać.
• Terminy – samoidentyfikacja i rejestracja: 6 miesięcy od wejścia w życie. SZBI: 12 miesięcy. Audyt podmiotów kluczowych: do 24 miesięcy od kwalifikacji, potem co 2 lata obowiązkowo.
• Zgłaszanie incydentów – 24 h jako wczesne ostrzeżenie → 72 h – pełne zgłoszenie → miesiąc – raport końcowy, wszystko przez system S46 do właściwego CSIRT (NASK, GOV lub MON).
• Art. 21 ust. 2 – 10 wymaganych środków zarządzania ryzykiem, od (a) do (j). To jest to, co będzie mapowane na nasze dashboardy.

Art. 21 ust. 2 w skrócie:

To minimum. Każdy z tych punktów musi być zatwierdzony przez organ zarządzający – to nie jest checklista dla admina, to dokument z podpisem prezesa.

Dlaczego Wazuh i Zabbix razem?

Bo to klasyczny błąd, który widzę w prawie każdym wdrożeniu: ludzie wybierają jedno z dwóch, a potem łatają drugą rolę skryptem w cronie.

• Wazuh to system SIEM z dodatkiem XDR. Robi analizę logów, detekcję zagrożeń, FIM, SCA, Vulnerability Detector, Active Response, mapowanie MITRE ATT&CK i natywne raporty compliance. Pokrywa 8 z 10 punktów art. 21 NIS 2 bezpośrednio.
• Zabbix to monitoring infrastruktury pod kątem problemów. Niekoniecznie od razu związanych z bezpieczeństwem. Robi: dostępność, wydajność, pojemności, SLA, escalation, predykcję (trigger prototypes). Pokrywa to, czego Wazuh dotyka tylko pobieżnie – art. 21(c) (ciągłość działania) i pośrednio (f) (ocena skuteczności, bo mamy trendy, nie punktowe wartości).

Oba rozwiązania reprezentują nurt open-source (Wazuh – GPLv2, Zabbix – AGPL), oba skalują się do setek tysięcy hostów, oba mają dobre API i mechanizmy integracji. Razem dają realne pokrycie monitoringu i bezpieczeństwa. I – co niebagatelne dla audytora – oba mają gotowe raporty, które można wydrukować i włożyć do segregatora “SZBI”.

Mapowanie art. 21 NIS 2 → moduły Wazuh

Poniżej tabelka, którą warto wydrukować i powiesić w pokoju SOC:

Wazuh natywnie pokrywa 8 z 10 punktów. Punkty (d) i (g) wymagają wsparcia procesowego – umów z dostawcami, szkoleń, platformy e-learning — ale Wazuh do tego dostarczy dane techniczne.

Mapowanie art. 21 NIS 2 → Zabbix

Zabbix nie jest SIEM-em, więc nie mapujmy go siłą do takich funkcji. Za to pomaga tam, gdzie Wazuh nie radzi sobie z inwentaryzacją:

Ostatni punkt jest krytyczny i zaskakująco często pomijany: jeśli Wazuh Manager się wywróci, a SIEM nikomu nie zasygnalizuje tego faktu, to przez najbliższe godziny administratorzy mogą być ślepi i głusi. Zabbix z prostym itemem net.tcp.service[tcp,,1514] i triggerem na nodata(5m) ratuje ten scenariusz… za darmo.

Pierwsza linia – FIM + Active Response [art. 21(2)(b), (i)]

Funkcja Wazuha – File Integrity Monitoring to absolutne minimum pod zgłaszanie incydentów w reżimie 24 / 72 h. Bez mechanizmu who-data nie jesteście w stanie odpowiedzieć audytorowi na pytanie “Kto zmodyfikował /etc/passwd o 3:17 w nocy?” potwierdzając, że infrastruktura nie jest rozliczalna (a to przecież jeszcze za czasów RODO!)

Zatem tutaj proponowana konfiguracja ossec.conf dla krytycznych ścieżek z raportowaniem zmian:

<syscheck>   <frequency>300</frequency>   <scan_on_start>yes</scan_on_start>   <!-- Linux critical files -->   <directories realtime="yes" whodata="yes" check_all="yes"     report_changes="yes">/etc,/usr/bin,/usr/sbin</directories>   <directories realtime="yes" whodata="yes"     report_changes="yes">/var/www/html</directories>   <!-- Windows critical -->   <directories realtime="yes" check_all="yes"     report_changes="yes">C:\Windows\System32\drivers\etc</directories>   <directories realtime="yes" check_all="yes"     report_changes="yes">C:\inetpub\wwwroot</directories>   <!-- Registry -->   <windows_registry arch="both">     HKEY_LOCAL_MACHINE\Software\Policies</windows_registry>   <windows_registry arch="both">     HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services</windows_registry>   <!-- Wykluczenia szumu -->   <ignore>/etc/mtab</ignore>   <ignore type="sregex">\.log$|\.tmp$</ignore> </syscheck>

Poniżej znajdziecie także wzór (fundament) własnej reguły mapowania 1:1 na art. 21 — żeby compliance officer nie musiał zgadywać, po co ona w ogóle jest:

<group name="nis2,syscheck,critical_files">   <rule id="100300" level="12">     <if_sid>550</if_sid>     <field name="syscheck.path">/etc/passwd</field>     <description>NIS2 Art.21(2)(i): /etc/passwd modified — possible       unauthorized user creation</description>     <group>nis2_art21i,iam,critical</group>     <mitre>       <id>T1136.001</id>     </mitre>   </rule>   <rule id="100301" level="14">     <if_sid>550</if_sid>     <field name="syscheck.path">/etc/shadow</field>     <description>NIS2: /etc/shadow modified — credential tampering</description>     <group>nis2_art21i,credentials,critical</group>     <mitre>       <id>T1003.008</id>     </mitre>   </rule> </group>

Po co tag <mitre>? Bo audytor z NIS 2 nie musi znać matrycy ATT&CK, ale jeśli w raporcie zobaczy ID techniki, a w dashboardzie gotowy heatmap – to załatwia jego pytanie “Jakie mamy środki detekcyjne?”.

Dla art. 21(2)(b) – reagowanie. W Wazuh istnieje mechanizm Active Response, czyli dodatek XDR. Proste blokowanie brute-force SSH może być realizowane w następujący sposób:

<command>   <name>firewall-drop</name>   <executable>firewall-drop</executable>   <timeout_allowed>yes</timeout_allowed> </command> <active-response>   <command>firewall-drop</command>   <location>local</location>   <rules_id>5763</rules_id>   <timeout>600</timeout>   <repeated_offenders>60,120,360</repeated_offenders> </active-response>

Oczywiście warto zwrócić uwagę, że jest to proaktywna ochrona tylko dla ataków siłowych na SSH. Jednak pokazuje to ideę i jak bardzo dobrze i kompleksowo można skonfigurować Wazuha pod kątem takich mechanizmów XDR.

I coś bardziej mięsistego, a subiektywnie obowiązkowego – detekcja masowej zmiany plików (klasyczny sygnał ransomware, T1486):

<group name="nis2,ransomware,syscheck">   <rule id="100200" level="14" frequency="20" timeframe="30">     <if_matched_group>syscheck_file</if_matched_group>     <description>NIS2: Possible ransomware — mass file modification       detected (20+ files/30s)</description>     <group>nis2_art21b,ransomware,attack</group>     <mitre>       <id>T1486</id>     </mitre>   </rule> </group>

Zatem jeśli art. 21(2)(b) wymaga “natychmiastowego reagowania”, to automatyczny skrypt firewall-drop i izolacja agenta jest literalnie tym, co opisuje ustawa.

Własna polityka SCA dla “NIS2 Baseline” [art. 21(2)(a), (e), (h)]

Metryki hardeningu CIS Benchmarks są świetne, ale audytor z NIS 2 nie zna CIS 5.2.10. Zna art. 21 ust. 2 lit. i. Dlatego w praktyce robimy sobie własną politykę Security Configuration Assessment SCA mapowaną bezpośrednio na artykuły UKSC / NIS 2. Przyczym zaznaczam na tym etapie, to fundament, do własnej rozbudowy w zależności od tego jaką działalnośc prowadzicie:

custom_nis2_baseline.yml:

policy:   id: "nis2_baseline"   file: "custom_nis2_baseline.yml"   name: "NIS2/UKSC Baseline Check"   description: "Custom policy for NIS2 compliance"   references:     - https://eur-lex.europa.eu/eli/dir/2022/2555 checks:   - id: 90001     title: "SSH root login disabled"     description: "Art.21(2)(i) - Access control"     compliance:       - nis2: "Art.21.2.i"       - cis: "5.2.10"     condition: all     rules:       - 'f:/etc/ssh/sshd_config -> r:^PermitRootLogin\s+no'   - id: 90002     title: "Password min length >= 12"     compliance:       - nis2: "Art.21.2.i"     condition: all     rules:       - 'f:/etc/security/pwquality.conf -> r:minlen\s*=\s*\d{2,}'

I włączamy ją w konfiguracji agenta ossec.conf (można też dla grupy agentów z poziomu serwera) obok standardowych polityk CIS:

<sca>   <enabled>yes</enabled>   <scan_on_start>yes</scan_on_start>   <interval>12h</interval>   <policies>     <policy>cis_debian10.yml</policy>     <policy>cis_win2022.yml</policy>     <policy>custom_nis2_baseline.yml</policy>   </policies> </sca>

Opisując powyższe, alert w dashboardzie wpada z oznaczeniem compliance.nis2 = "Art.21.2.i", więc możemy potem prostym filtrem wygenerować raport “wszystkie failed checks mapowane na art. 21 ust. 2 lit. i” i wkleić go do dokumentacji SZBI. To już trochę game-changer.

Podatności: art. 21(2)(e) – mechanizm Vulnerability Detector

Szczerze mówiąc dla Wazuha to najprostsze mapowanie. Art. 21(2)(e) wprost mówi o “ujawnianiu podatności”. Wazuh robi to w trybie out of the box idąc za dokumentacją:

<vulnerability-detector>   <enabled>yes</enabled>   <interval>5m</interval>   <min_full_scan_interval>6h</min_full_scan_interval>   <run_on_start>yes</run_on_start>   <provider name="nvd">     <enabled>yes</enabled>     <update_interval>1h</update_interval>   </provider>   <provider name="canonical">     <enabled>yes</enabled>     <os>jammy</os>   </provider>   <provider name="msu">     <enabled>yes</enabled>     <update_interval>1h</update_interval>   </provider> </vulnerability-detector>

Poniżej raport krytycznych podatności CVE per agent – skrypt, który warto wpiąć w mechanizm cron i wysyłać do IOD:

#!/bin/bash # NIS2 Art.21(2)(e) — raport krytycznych podatności TOKEN=$(curl -s -u wazuh-wui:MyPass -k -X POST \   "https://localhost:55000/security/user/authenticate" | jq -r '.data.token') curl -s -k -X GET "https://localhost:55000/vulnerability/003" \   -H "Authorization: Bearer $TOKEN" | \   jq '.data.affected_items[] | select(.severity=="Critical") |   {cve: .cve, package: .name, version: .version, cvss: .cvss3_score}'

Na jednej kartce papieru mamy wtedy konkretne CVE, konkretne pakiety do podmiany. Tak powinna wyglądać “obsługa podatności” w rozumieniu UKSC.

Zabbix w tej układance – ciągłość i wartość SLA [art. 21(2)(c)]

Art. 21(2)(c) mówi o ciągłości działania, backupach i zarządzaniu kryzysowym. Sam Wazuh zobaczy, że agent przestał wysyłać zdarzenia, ale nie odpowie Wam, czy usługa biznesowa na hoście działa, czy backup wystartował o czasie i czy dysk nie dojdzie do 100% za 4 dni. To zrobi nieśmiertelny Zabbix.

Minimalny zestaw itemów w Zabbixie pod NIS 2 / UKSC:

# Dostępność SIEM-a (Art. 21(2)(b) — bez tego nie ma detekcji) net.tcp.service[tcp,,1514]             # Wazuh agent comms net.tcp.service[tcp,,55000]            # Wazuh API net.tcp.service[https,,9200]           # Indexer # Dostępność krytycznych usług (Art. 21(2)(c)) net.tcp.service[https,app.example.pl,443] net.udp.service[ntp,ntp.example.pl,123] # Kapacyty — predykcja awarii vfs.fs.size[/var,pfree]                # free % # Trigger: predykcja wyczerpania w < 7 dni # {host:vfs.fs.size[/var,pfree].forecast(1d,,7d)} < 10 # Backup — Art. 21(2)(c) vfs.file.time[/backup/last_success,modify] # Trigger: (now - last_success) > 26h → backup nie wystartował

Drugie mapowanie w Zabbiksie – raporty SLA. Jeżeli w dokumentacji SZBI deklarujecie dostępność usługi kluczowej na poziomie 99,5%, to przy kontroli ktoś zada wprost pytanie: “na jakiej podstawie to mierzycie?”. Zabbix IT Services + SLA reports dają Wam gotowy PDF na tę odpowiedź. Wazuh takiej funkcji wbudowanej nie ma.

Trzecie mapowanie to eskalacja. Akcje Zabbixa z wartością escalation_step od 0 do N pozwalają zmapować realny playbook: pierwszy SMS do dyżurnego po 5 min, ticket do zespołu L2 po 15 min, następnie telefon do managera po 30 min. To jest, literalnie, “obsługa incydentu” z art. 21(2)(b) w warstwie infrastruktury. Wszystkie mapowania robimy na szkoleniu Zabbix Expert.

Raportowanie incydentów do S46 – 24 h / 72 h / miesiąc

Zgłoszenie do CSIRT w terminie 24 h jest niewykonalne bez SIEM-a. Nie dlatego, że nie zdążycie wpisać do formularza S46, tylko dlatego, że nie będziecie wiedzieli, co wpisać. Co dokładnie Wazuh daje jako “dowody” do raportu:

• Wczesne ostrzeżenie (24 h) – alerty z level >= 10, agent, czas, reguła, technika z MITRE ATT&CK. Raport JSON z /var/ossec/logs/alerts/alerts.json.
• Zgłoszenie incydentu (72 h) – korelacja: łańcuch reguł, który zaalertował, whodata z FIM (UID, PID, proces-rodzic), logi uwierzytelnienia, CVE z Vulnerability Detector (jeśli wektor jest znany).
• Raport końcowy (miesiąc) – SCA przed / po (czy naprawiliśmy konfigurację?), lista zmodyfikowanych plików, timeline zdarzeń, Active Response – co zostało proaktywnie ochronione.

Do S46 wysyłamy ręcznie albo przez API (które CSIRT NASK wystawia), ale zbiór danych do raportu powinien być generowany automatycznie w momencie utworzenia incydentu – najlepiej integracją Wazuh → TheHive lub JIRA i następnie do generatora PDF. Inaczej Wasz SOC analityk spędzi 20 h na kopiowaniu JSON-ów z dashboardu…

Role w zespole – co kto robi

To pytanie, które pada na każdej rozmowie wdrożeniowej, więc domykam temat kolejną ładną tabelką:

Minimalny zespół pod UKSC dla podmiotu kluczowego w modelu 8 x 5 + on-call: 4–5 osób. Dla 24 / 7 – 8–10 osób. Całkowity outsourcing do MSSP też jest OK, ale odpowiedzialność kierownika zostaje w firmie – tego nie delegujecie.

Retencja logów – praktyczny model

UKSC i NIS 2 nie narzucają sztywnej retencji, ale audytorzy patrzą na to, co branża uznaje za dobre praktyki. Zatem z mojego doświadczenia, oraktyczny model, który działa w SOC-ach:

• strefa Hot (Wazuh Indexer, na dyskach minimum SSD) – 30–60 dni, pełny index, szybkie query.
• strefa Warm (dyski NL-SAS, HDD, mniej shardów (retencji indeksów)) – 6–12 miesięcy, rare query, raport compliance.
• strefa Cold (snapshot do np. taniego S3 / MinIO)– 24+ miesięcy, na potrzeby audytu post factum.
• akcja Delete / Rollover – po upływie retencji, z rejestrem zniszczenia (obowiązkowo!).

Dla podmiotu kluczowego z obowiązkiem audytu co 2 lata – minimum 24 miesiące cold storage. Dla zdrowia (HIPAA) i finansów (PCI DSS 4.0) osobne reżimy, zwykle surowsze. Dobierane indywidualnie per organizacja. Natomiast plan retencji musi być w SZBI – inaczej pierwszy kontroler z urzędu zapyta: “A co z logami z października 2026?” – i lepiej żebyście znali odpowiedź :-).

Czego Wazuh i Zabbix nie załatwią

Żeby nie było, że pokazuje Wam panaceum na to wszystko. Nigdy tak nie jest. Lista rzeczy, których żaden SIEM i żaden monitoring nie załatwi, a które są wymogiem UKSC to:

• Formalne polityki bezpieczeństwa i dokumentacja SZBI – to robota dla compliance/consultingu.
• Plan ciągłości działania (BCP) i Disaster Recovery (DR) – Wazuh/Zabbix monitorują, ale plan i testy DR to procedury.
• Szkolenia personelu i zarządu – art. 21(2)(g). Platforma e-learningowa, testy phishingowe (polecam scamy.sekurak.pl oraz szkolenia NIS 2 dla zarządu jako punkt startowy, robimy także testy phishingowe).
• Audyty łańcucha dostaw – art. 21(2)(d). Wymaga umów, SLA, SBOM, przeglądów dostawców. Dane techniczne z Wazuha są wsparciem, nie zastępstwem.
• Aspekty prawne i regulacyjne – to zadanie dla i zespołu compliance.
• Fizyczne bezpieczeństwo – kamery, kontrola dostępu, bezpieczeństwo DC. Możemy też przetestować bezpieczeństwo fizyczne za Was :-)

Pełna zgodność = Wazuh + Zabbix + procesy organizacyjne + dokumentacja + ludzie + audyty. SIEM to fundament techniczny, nie cały dom.

Checklista wdrożeniowa

Dla tych, którzy czytają do tego momentu z kawą i notatnikiem przekazuję konkretną kolejność kroków, która najrzadziej będzie wybuchać w trakcie wdrożenia (moim zdaniem):

1. Samoidentyfikacja – czy podmiot kluczowy czy ważny (do 10.2026).
2. Rejestracja w wykazie przez odpowiedni CSIRT.
3. Inwentaryzacja aktywów – Zabbix LLD + host inventory, wsad do SZBI.
4. Wdrożenie klastra Wazuh (Manager + Indexer + Dashboard) – single node na start, klaster przy > 200 końcówek (komputery i sprzęty).
5. Agenty Wazuh – Linux, Windows, sieć (syslog), chmura (CloudTrail / Activity Log / Audit Log).
6. Polityki SCA — CIS Benchmarks + własny ww. nis2_baseline.yml.
7. Vulnerability Detector — NVD + feedy OS.
8. FIM z whodata na krytyczne ścieżki.
9. Active Response – przynajmniej skrypty wbudowane jak firewall-drop na brute-force i typowe ataki.
10. Dedykowane reguły (np. z SOCFortress) – MITRE tags + compliance tags (nis2_art21*).
11. Zabbix – monitoring infrastruktury + samego Wazuha.
12. Integracja z S46 / CSIRT – szablon zgłoszenia, playbook 24 / 72 h.
13. Retencja – strefy hot / warm / cold + snapshot policy.
14. Dokumentacja SZBI – zatwierdzenie przez zarząd.
15. Audyt wewnętrzny – przed kontrolą z UKE / właściwego organu.
16. Audyt zewnętrzny i szkolenia (np. z Securitum a co!)

Podsumowanie

UKSC jest już w mocy, kary są realne, a odpowiedzialność zarządu – osobista. Dobra wiadomość jest taka, że zarządzania technicznego wymaganiami art. 21 ust. 2 NIS 2 nie trzeba kupować – Wazuh pokrywa 8 z 10 punktów natywnie, Zabbix dokłada ciągłość i SLA, obydwa darmowe, obydwa produkcyjnie sprawdzone. Zła wiadomość to samo uruchomienie oprogramowania to jakieś 30% roboty, więc potrzebne są kompetencje. Reszta – reguły mapowane 1:1 na artykuły, polityka SCA nis2_baseline.yml, integracja z S46, playbook 24 / 72 h, SZBI z podpisem zarządu – to ciężar organizacyjny, który spadnie na SOC, compliance i radców. Natomiast jak trzeba to trzeba.

~Tomek Turba