SIEM, NIS2 i ISO: praktyka wdrożenia

SIEM w praktyce: luka między monitoringiem a wymaganiami NIS2

To case study dokumentuje praktyczne wdrożenie Wazuh SIEM w środowisku testowym Proxmox. Celem było połączenie teorii GRC z rzeczywistością operacyjną – sprawdzenie, co SIEM naprawdę dostarcza w zakresie monitoringu, wykrywania podatności i praktycznych danych o ryzyku.

Dlaczego ten projekt ma znaczenie (perspektywa praktyczna)

W obszarze GRC łatwo spełnić wymagania formalne: polityki, procedury, zapisy audytowe.
Znacznie trudniej zbudować realną zdolność wykrywania incydentów.

Ten projekt powstał, aby zweryfikować w praktyce:

• czy monitoring rzeczywiście pozwala identyfikować incydenty,
• jakie dane mają realną wartość dla analizy ryzyka,
• gdzie kończy się compliance, a zaczyna operacyjne bezpieczeństwo.

SIEM w kontekście NIS2 i UKSC – gdzie jest realna luka?

Dyrektywa NIS2 oraz krajowe regulacje wymagają nie tylko wdrożenia polityk bezpieczeństwa, ale realnej zdolności do:

• wykrywania incydentów,
• reagowania,
• raportowania zdarzeń.

W praktyce raporty sektorowe regularnie pokazują, że między spełnieniem wymagań formalnych a gotowością operacyjną nadal występuje luka. Najczęściej dotyczy ona obszarów takich jak:

• centralnej analizy logów,
• korelacji zdarzeń,
• widoczności incydentów w czasie rzeczywistym.

W tym kontekście SIEM przestaje być narzędziem technicznym – staje się elementem budowania rzeczywistej zdolności operacyjnej.

Kuchnia technologiczna: Proxmox i rzeczywistość wdrożenia

Wazuh został wdrożony jako maszyna wirtualna w środowisku Proxmox. Już na starcie pojawiło się wyzwanie, które uczy pokory wobec technologii.

Kuchnia wdrożenia: Wazuh jako VM w środowisku Proxmox.

Minimalne wymagania przyjęte w tym środowisku testowym

W tej implementacji przyjęto konfigurację startową opartą na zasobach widocznych na zrzucie środowiska. To praktyczny punkt odniesienia dla środowiska testowego, a nie uniwersalne minimum dla każdego wdrożenia produkcyjnego.

• CPU: 4 vCPU
• RAM: 4 GiB
• Dysk: ok. 40 GiB (39.08 GiB)
• SWAP: 512 MiB
• System: Debian (kontener/VM w Proxmox)

Wazuh dostarczany jest w formacie OVA, który nie jest natywnie wspierany przez Proxmox. Wymagało to ręcznej konwersji dysków i importu przez CLI (Command Line Interface). To świetnie pokazuje różnicę między wdrożeniem "teoretycznym" a rzeczywistym - tutaj nie ma przycisku "Next", jest zrozumienie architektury.

Monitorowane środowisko obejmuje:

• 2 x Windows (różne wersje)
• 1 x Linux (Debian VM jako serwer usług)

Zastosowałem segmentację sieci (VLAN), aby oddzielić ruch monitorowany. Wymusiło to konfigurację odpowiednich reguł na firewallu - agenty muszą mieć dostęp do serwera, ale bez otwierania zbędnych "drzwi" w sieci.

Widoczność endpointów - fundament kontroli zasobów.

Co faktycznie pokazał system?

• Podatności: Nawet w małym, kontrolowanym środowisku system ujawnił wiele podatności, w tym o wysokiej i krytycznej istotności (High/Critical).
• Aktualizacje: Potwierdziło się, że "aktualny system" to mit. Część podatności wynika z zależności, bibliotek i konfiguracji, których standardowy proces aktualizacji systemu nie zawsze obejmuje w pełnym zakresie.
• Widoczność: Jasno widać, które zasoby utrzymują ciągłość raportowania, a które wymagają interwencji i przywrócenia pełnej obserwowalności (status agentów).

Rzeczywisty poziom podatności - od tego zaczyna się analiza ryzyka.

Reality check: dlaczego logi to jeszcze nie bezpieczeństwo

• logi ≠ bezpieczeństwo
• monitoring ≠ detekcja
• detekcja ≠ reakcja
• reakcja ≠ zarządzanie ryzykiem

Dopiero połączenie tych elementów daje realną wartość.

Perspektywa ISO/IEC 27001 i ISO/IEC 27002 - Co wynika dla praktyki?

Dzięki temu projektowi, kontrole z nowej wersji normy przestały być tylko numerami:

• ISO/IEC 27001:2022: definiuje wymagania systemowe ISMS i odpowiedzialność organizacji za skuteczność zabezpieczeń.
• ISO/IEC 27002:2022: doprecyzowuje praktyki wdrożeniowe oraz sposób realizacji i utrzymania kontroli.
• 8.15 (Logging): Nadmiar danych to szum. Kluczowa jest selekcja - co logujemy, by móc odtworzyć incydent, nie zapychając dysków.
• 8.16 (Monitoring activities): Bez kontekstu biznesowego monitoring to tylko migające kontrolki. Trzeba wiedzieć, co jest "normalne".
• 8.8 (Management of technical vulnerabilities): Realna widoczność podatności w SIEM drastycznie skraca czas reakcji (Time-to-Remediate).

Najważniejszy wniosek: monitoring nie polega na zbieraniu danych, ale na podejmowaniu decyzji w oparciu o kontekst ryzyka i zdolność reakcji.

Audytorskie "Aha!": Zarządzanie podatnościami

Doświadczenie z projektu pozwoliło doprecyzować pytania audytowe tak, aby oceniały skuteczność procesu, a nie samą obecność narzędzia.

• Kryteria priorytetyzacji: Jakie formalne kryteria (CVSS, kontekst biznesowy, ekspozycja zasobu) decydują o kolejności działań i gdzie są one zatwierdzone?
• Dowody skuteczności: Jakie mierniki potwierdzają skuteczność procesu (np. dotrzymanie SLA, trend redukcji ekspozycji, odsetek zamkniętych działań)?
• Zarządzanie odstępstwami: Jak postępuje się w sytuacji, gdy nie można usunąć podatności w wymaganym terminie: kto akceptuje ryzyko i jakie zabezpieczenia tymczasowe są wdrażane?
• Zamknięcie i nadzór: Jak wygląda formalne zamknięcie podatności i kto je zatwierdza?

File Integrity Monitoring (FIM)

Przetestowałem monitorowanie zmian w plikach konfiguracyjnych (np. w folderze `/etc/` na Linuxie oraz kluczowych gałęziach Rejestru Windows).

Wniosek? Narzędzie działa brutalnie skutecznie - wykryje każdą zmianę, ale jeśli nie zdefiniujesz co i dlaczego monitorujesz, utoniesz w alertach przy każdej aktualizacji systemu.

Moje środowisko testowe vs rzeczywistość

Podsumowanie

Wdrożenie SIEM, nawet w środowisku testowym, pokazuje jedną kluczową rzecz:
różnicę między deklarowanym a rzeczywistym poziomem bezpieczeństwa.

W praktyce nie chodzi o to, czy system istnieje, ale:
czy organizacja potrafi wykrywać zdarzenia, interpretować je i podejmować adekwatne działania.

To właśnie ten obszar najczęściej ujawnia największą lukę między compliance a rzeczywistością operacyjną.

W praktyce warto zadać jedno pytanie:
czy widzimy incydenty, czy tylko zbieramy dane?

Rekomendacje (na bazie uznanych praktyk)

• Powiązanie SIEM z ryzykiem: każda krytyczna reguła i alert powinny mieć przypisanego właściciela ryzyka oraz zdefiniowany czas reakcji (ISO/IEC 27001:2022, NIST CSF 2.0).
• Ustalenie minimalnego zestawu KPI bezpieczeństwa: czas detekcji (MTTD), czas reakcji (MTTR), udział podatności krytycznych zamkniętych w SLA oraz trend ekspozycji podatności miesiąc do miesiąca.
• Cykliczne przeglądy skuteczności kontroli: kwartalny przegląd jakości logowania, reguł detekcji i fałszywych alarmów (ISO/IEC 27002:2022).
• Procesowe zarządzanie podatnościami: identyfikacja, analiza, priorytetyzacja, remediacja lub mitygacja, weryfikacja oraz formalne zamknięcie - zgodnie z podejściem opisanym w NIST SP 800-40r4 oraz kontrolą 8.8 normy ISO/IEC 27002:2022.
• Budowanie odporności organizacji, nie tylko zgodności: łączenie monitoringu z procesem zarządzania ryzykiem, planami ciągłości działania i cyklicznym przeglądem skuteczności zabezpieczeń, zgodnie z aktualnymi wytycznymi NIST oraz rekomendacjami ENISA.

Źródła i dokumenty odniesienia

• ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements.
• ISO/IEC 27002:2022 - Information security, cybersecurity and privacy protection - Information security controls.
• NIST Cybersecurity Framework (CSF) 2.0.
• NIST SP 800-40r4 - Guide to Enterprise Patch Management Planning.
• NIST SP 800-61 - Computer Security Incident Handling Guide (odniesienie metodyczne).
• ENISA guidance and good practices for incident response and vulnerability management.
• ENISA Threat Landscape (aktualne wydania) - przegląd trendów zagrożeń i dojrzałości praktyk bezpieczeństwa.
• Verizon Data Breach Investigations Report (DBIR, aktualne wydania) - analiza rzeczywistych incydentów i wzorców ataków.
• Mandiant M-Trends (aktualne wydania) - obserwacje operacyjne dotyczące wykrywania i reagowania na incydenty.