Dlaczego ten projekt powstał? (Moja perspektywa)

W świecie GRC łatwo zostać teoretykiem. Można znać normy na pamięć, ale bez zrozumienia, jak dane faktycznie "płyną" w systemie, audyt staje się powierzchowny. Ten projekt powstał z ciekawości i potrzeby zrozumienia:

• Jak wygląda wdrożenie SIEM od strony operacyjnej (od kuchni).
• Jakie dane są rzeczywiście zbierane i jak przekładają się na ryzyko.
• Co ma realną wartość dla bezpieczeństwa, a co jest tylko "dobrą praktyką" w dokumentacji.

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 do technologii.

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

Minimalne wymagania przyjęte w tym LAB

W tej implementacji przyjęto konfigurację startową opartą o zasoby widoczne na zrzucie środowiska. To praktyczny punkt odniesienia dla małego LAB-u, 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.

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 tylko na zbieraniu danych, ale na podejmowaniu decyzji - co jest akceptowalnym ryzykiem, a co wymaga natychmiastowego działania.

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.

Podsumowanie porównawcze: LAB i biznes

Podsumowanie

Wdrożenie SIEM w środowisku laboratoryjnym o ograniczonej skali może być nieproporcjonalne do ryzyka, ale daje coś bezcennego: autentyczne zrozumienie mechanizmów obronnych.

Jako audytor i osoba zajmująca się bezpieczeństwem wiem, że w bezpieczeństwie nie chodzi o to, czy system istnieje - ale o to, czy potrafimy właściwie interpretować sygnały i przekładać je na konkretne działania.

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.