Często kiedy słyszymy słowo „compliance”, w głowie pojawia nam się obraz segregatorów pełnych nudnych procedur i audytorów skrupulatnie wytykających wszelkie niezgodności. W rzeczywistości jednak zgodność z normami to po prostu zestaw dobrych praktyk. To fundament, który pomaga firmom uporządkować procesy, zabezpieczyć aktywa cyfrowe i – co najważniejsze – budować pozycję wiarygodnego partnera w biznesie. W czasach, gdy cyfryzacja przyspieszyła jak nigdy wcześniej, bycie „compliant” to już nie tylko kwestia formalności, ale element dojrzałości biznesowej.
Doskonałym przykładem są obowiązująca w Europie od stycznia 2026 roku dyrektywa NIS2 oraz wdrożona na jej kanwie w Polsce (w kwietniu 2026 roku) nowelizacja ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC2). Obie te regulacje drastycznie rozszerzają listę podmiotów, które muszą spełniać rygorystyczne normy bezpieczeństwa. Zmiany te objęły już nie tylko gigantów infrastruktury krytycznej, ale także setki średnich i dużych przedsiębiorstw z sektorów takich jak logistyka, energetyka, produkcja czy medycyna. Co ciekawe, nawet jeśli Twoja firma nie należy bezpośrednio do tego grona, NIS2 oraz KSC2 mogą posłużyć jako świetna baza do stworzenia własnego, wewnętrznego systemu zarządzania bezpieczeństwem.
Wprowadzenie tych standardów w życie to jednak spore wyzwanie logistyczne i finansowe. Na szczęście nowoczesne podejście do cyberbezpieczeństwa nie wymaga już kupowania astronomicznie drogich, zamkniętych systemów. Z pomocą przychodzi świat open source, a na jego czele stoi platforma Wazuh. W tym artykule przyjrzymy się, jak to jedno elastyczne narzędzie pozwala płynnie i bez budżetowej rewolucji dostosować infrastrukturę firmy do wymogów NIS2 oraz polskiego KSC2.
Czym właściwie jest platforma Wazuh?
Zanim przejdziemy dalej, warto zadać sobie podstawowe pytanie: czym dokładnie jest Wazuh? W najprostszych słowach to otwartoźródłowa platforma bezpieczeństwa, która łączy w sobie dwie kluczowe role: SIEM (system do zbierania i analizowania logów w czasie rzeczywistym z całej naszej infrastruktury) oraz XDR (narzędzie do aktywnego wykrywania zagrożeń i reagowania na nie bezpośrednio na urządzeniach końcowych).
Jego siła tkwi w elastyczności. Architektura Wazuha opiera się na lekkich agentach instalowanych na monitorowanych systemach. Oprócz tego platforma świetnie radzi sobie bezagentowo (agentless) oraz przy użyciu API, dzięki czemu potrafi zbierać dane z niemal każdego zakątka firmowego środowiska. Bez problemu monitoruje:
- Systemy operacyjne (Windows, Linux, macOS),
- Chmury i kontenery (AWS, Azure, Docker, Kubernetes),
- Aplikacje i usługi (np. Microsoft 365, bazy danych),
- Urządzenia sieciowe (firewalle, routery).
Wazuh działa jak całodobowy cyfrowy strażnik. Co ważne, nie ogranicza się jedynie do biernego informowania nas o zagrożeniach. Dzięki wbudowanemu modułowi active-response potrafi automatycznie reagować na incydenty w czasie rzeczywistym – na przykład uruchamiając dedykowany skrypt na zaatakowanej końcówce i natychmiastowo izolując zagrożenie.
Skoro kwestie teoretyczne mamy już za sobą, czas przejść do konkretów. Przyjrzyjmy się funkcjom, które oferuje Wazuh i zobaczmy, jak w praktyce pomagają one zadbać o zgodność z przepisami.
Na potrzeby demonstracji przygotowałem małe środowisko testowe (lab): centralny serwer Wazuh (w architekturze single-node) w wersji 4.14.5 oraz cztery hosty testowe: Debian 13, Ubuntu 24.04 LTS, Windows 11 oraz macOS 15.4.
Utwardzanie systemów, czyli fundamenty NIS2/KSC2
Dyrektywy prawne czy standaryzacje często wymagają od firm regularnej oceny stanu bezpieczeństwa. Nie możesz zabezpieczyć czegoś, o czym nie wiesz, lub co domyślnie jest skonfigurowane w podatny sposób. Z pomocą przychodzi nam tutaj moduł Wazuha o nazwie Security Configuration Assessment (SCA). Skanuje on automatycznie systemy wpięte do naszej platformy i weryfikuje ich zgodność z benchmarkami CIS (zestawem dobrych praktyk konfiguracji dla Linux/Windows/MacOS).
W wyniku skanowania dostajemy informację, ile punktów kontrolnych dany host spełnia, dokładną listę punktów do poprawy w konfiguracji, a także ogólny score naszego hosta. Pokazuje to czarno na białym administratorom, a także audytorowi, że systemy są utwardzone oraz spełniają odpowiednie normy bezpieczeństwa.
Rozwijając poszczególne punkty kontrolne, możemy przy każdym z nich znaleźć dokładną informację, czego on dotyczy, a także co musimy poprawić w naszym systemie, aby był on z nim zgodny.
Jeżeli domyślnie dołączone do systemu benchmarki CIS nie spełniają naszych oczekiwań, możemy stworzyć też własne polityki, odpowiednio dopasowane do potrzeb naszej organizacji. Same polityki SCA pisze się w YAML’u, więc jest to bardzo wygodne. Poniżej przykładowa polityka weryfikująca, czy SSH jest odpowiednio zabezpieczone:
policy:
id: "internal_ssh_hardening"
file: "ssh_policy.yml"
name: "Dedicated SSH Hardening Policy"
description: "SSH server configuration hardening policy for Linux systems."
references:
- https://www.ssh.com/academy/ssh/sshd_config
requirements:
title: "Check if SSH configuration file exists"
description: "Requirements for running the SCA scan against the SSH hardening policy."
condition: all
rules:
- "f:/etc/ssh/sshd_config"
checks:
- id: 90001
title: "Disable direct root login via SSH"
description: "Enforcing login as a regular user minimizes the risk of unauthorized access."
remediation: "Set PermitRootLogin no in /etc/ssh/sshd_config."
condition: all
rules:
- "f:/etc/ssh/sshd_config -> !r:^# && r:PermitRootLogin\\s+no"Oczywiście ręczne kopiowanie plików na każdy serwer z osobna mija się z celem (zwłaszcza w większych środowiskach). Aby rozesłać naszą politykę masowo do wielu agentów jednocześnie, wykorzystamy mechanizm grup. W tym celu musimy utworzyć nową grupę i dodać do niej hosty, które chcemy objąć daną polityką. Możemy to zrobić w prosty sposób bezpośrednio w panelu Wazuha, przechodząc do zakładki Agents management -> Groups.
Mając już gotową grupę, przechodzimy na serwerze do katalogu /var/ossec/etc/shared/nazwa_grupy/ i to właśnie w nim umieszczamy plik z naszą nową polityką. Pamiętaj też, aby nadać mu odpowiednie uprawnienia komendą chown wazuh:wazuh ssh_policy.yml (w przeciwnym razie serwer nie będzie mógł go poprawnie przetworzyć). Po chwili plik zostanie automatycznie zsynchronizowany i rozesłany do wszystkich hostów przypisanych do tej grupy.
W ostatnim kroku musimy przejść do konfiguracji wybranej grupy agentów i dodać odpowiedni wpis, który wskazuje naszą nową politykę SCA. Zostanie on automatycznie rozesłany do urządzeń końcowych i dynamicznie podpięty pod ich główny plik konfiguracyjny (ossec.conf).
Po zaledwie kilku sekundach konfiguracja na końcówkach powinna się zaktualizować, a my w panelu modułu SCA bez problemu zobaczymy nowy zestaw kontroli dla naszej spersonalizowanej polityki.
Spersonalizowane polityki to świetne narzędzie, gdy nasz wewnętrzny system bezpieczeństwa lub wdrożone w organizacji standardy (takie jak np. ISO 27001) wymagają od nas przestrzegania konkretnych środków kontrolnych w konfiguracji systemów.
Warto też wspomnieć, że domyślnie skany zgodności modułu SCA są przeprowadzane na hostach co 12 godzin. Oczywiście możemy ten czas elastycznie dostosować do własnych potrzeb, modyfikując parametr <interval> we wspomnianym wcześniej bloku <sca>:
<sca>
<enabled>yes</enabled>
<scan_on_start>yes</scan_on_start>
<interval>12h</interval>
<skip_nfs>yes</skip_nfs>
</sca>Moduł IT Hygiene – wgląd w posturę bezpieczeństwa systemów
Od niedawna Wazuh posiada w swoim arsenale zupełnie nowy, dedykowany moduł o nazwie „IT Hygiene”. To potężne narzędzie, które w jednym, skonsolidowanym widoku pozwala wyświetlić pełny obraz postury cyberbezpieczeństwa całej naszej infrastruktury. W praktyce oznacza to, że Wazuh bez przerwy prześwietla systemy, zainstalowane oprogramowanie, uruchomione procesy oraz warstwę sieciową. Wszystko po to, aby błyskawicznie wykryć błędy w konfiguracji, nieautoryzowane zmiany oraz wszelkie nietypowe anomalie.
Przejdziemy teraz krok po kroku po wszystkich zakładkach tego modułu i omówimy dokładnie, jaką realną wartość dają one zespołowi IT oraz Security w codziennej walce o compliance.
Główny ekran modułu IT Hygiene to miejsce, gdzie znajdziemy całościowe podsumowanie informacji o wszystkich systemach monitorowanych przez agenty Wazuha. Daje nam on natychmiastowy wgląd w architekturę naszego środowiska, agregując kluczowe metryki. Panel ten pozwala spojrzeć na całokształt monitorowanych przez nas systemów z lotu ptaka i natychmiast wyłapać anomalie, które mogą wymagać pilnej weryfikacji. Przykłady? Niestandardowy, nieautoryzowany port otwarty na jednym z serwerów czy nagły, podejrzany skok zużycia pamięci RAM na kluczowej maszynie.
Sekcja System pozwala nam zweryfikować, jakie dokładnie systemy operacyjne działają na naszych hostach oraz w jakich wersjach. To świetne narzędzie do sprawdzania, czy systemy w naszej firmie są zaktualizowane i czy gdzieś nie uchował się jakiś przestarzały OS. Oprócz tego możemy w tym miejscu podejrzeć hardware dostępny na maszynach, co daje szybki podgląd parametrów sprzętowych bez konieczności ręcznego logowania się na każdą końcówkę.
Sekcja Software daje nam pełną widoczność w aplikacje zainstalowane na naszych systemach Linux, macOS oraz Windows, a nawet w rozszerzenia do przeglądarek znajdujące się na hostach. Pozwala nam ona szybko zweryfikować, czy na którymś z hostów nie występuje nietypowa aplikacja, która może okazać się złośliwym oprogramowaniem wymagającym dokładnego sprawdzenia.
Sekcja Processes pozwala dokładnie sprawdzić, jakie procesy systemowe działają na naszych hostach. Podobnie jak w przypadku oprogramowania, daje nam to możliwość wykrycia anomalii i podejrzanych skryptów uruchomionych w tle, które ostatecznie mogą okazać się złośliwym oprogramowaniem.
Sekcja Network daje ogrom przydatnej wiedzy. Pozwala sprawdzić, jakich adresów IP używają nasze hosty, jakie interfejsy sieciowe posiadają, na jakich portach nasłuchują konkretne usługi, a nawet dokładnie zweryfikować logi z ruchu sieciowego dla poszczególnych maszyn. Jest to niezastąpione narzędzie, zwłaszcza podczas analizy incydentu bezpieczeństwa, kiedy chcemy szybko zweryfikować jego przebieg, komunikację z serwerem C2 (Command and Control) czy sam wektor ataku.
W naszym arsenale mamy też sekcję Identity, która pozwala zweryfikować, jacy użytkownicy i grupy istnieją na naszych hostach, jakie są ich katalogi domowe, a także z jakiej powłoki (shell) korzystają. Jest to świetne narzędzie, aby szybko wykryć nietypowe konta, które mogły zostać stworzone przez napastników jako backdoory służące do utrzymania trwałego dostępu do systemu.
No i na samym końcu zostaje nam sekcja Services, który pozwala zweryfikować usługi działające na naszych hostach. Dzięki temu możemy łatwo sprawdzić stan kluczowych serwisów w organizacji i upewnić się, że nie uruchomiło się tam nic, co np. mogłoby służyć jako ukryty mechanizm autostartu dla złośliwego kodu.
Jak już pewnie zdążyliście zauważyć, ten moduł daje jeszcze jedną ogromną wartość, która nie jest bezpośrednio związana z cyberbezpieczeństwem. Można go z powodzeniem użyć jako systemu do inwentaryzacji IT, który zbiera najważniejsze informacje administracyjne o naszych hostach i prezentuje je w jednej, przejrzystej formie. Jest to świetne rozwiązanie dla firm, które nie mają budżetu lub przestrzeni na deployment osobnego, dedykowanego do tego celu systemu.
💡 Perspektywa Compliance: Posiadanie aktualnej i automatycznej inwentaryzacji systemów to absolutny fundament w zasadzie każdego standardu bezpieczeństwa. To także kluczowy element zgodności z ISO 27001 i dyrektywą NIS2 w zakresie zarządzania ciągłością działania i architekturą sieci.
Wykrywanie podatności – wyprzedzić ruch napastnika
Skoro dzięki poprzedniemu modułowi zrobiliśmy porządną inwentaryzację systemów i wiemy dokładnie, co znajduje się na naszych hostach, czas pójść o krok dalej. Sam fakt, że wiemy, jakie aplikacje zainstalowane są w organizacji, to dopiero połowa sukcesu. Kluczowe pytanie brzmi: które z nich mają w sobie znane luki bezpieczeństwa, które napastnik może wykorzystać, aby dostać się do naszej sieci lub wyeskalować swoje uprawnienia w celu osiągnięcia swoich celów? Tutaj na scenę wkracza moduł Vulnerability Detection.
Nowe podatności (CVE) pojawiają się codziennie, a ręczne sprawdzanie, czy nasz soft jest bezpieczny, to syzyfowa praca. Bądźmy szczerzy, na to zwykle nie ma czasu, zwłaszcza jeżeli firma nie posiada dedykowanego zespołu SOC czy ludzi od cyberbezpieczeństwa, a cały ten temat muszą obsłużyć i tak już zawaleni bieżącą pracą administratorzy IT. Próba ręcznego śledzenia biuletynów bezpieczeństwa dla kilkudziesięciu aplikacji na setkach końcówek to z góry przegrana walka.
Magią tego modułu jest to, że jest on pasywny. Tradycyjne skanery podatności (np. Nessus czy OpenVAS) działają na zasadzie „uderzenia” w sieć – generują ruch, skanują porty, próbują logować się do usług. Robią to rzadko (np. raz w tygodniu lub w miesiącu), bo to obciąża infrastrukturę.
Wazuh robi to całkowicie inaczej i znacznie sprytniej:
- Wykorzystanie syscollector: Moduł ten nieustannie „wie”, co dzieje się na hoście, bo system operacyjny sam raportuje mu listę zainstalowanych paczek
.deb,.rpmczy programów w Windowsie. To lekkie zapytanie lokalne, które nie generuje żadnego narzutu na sieć. - Korelacja po stronie serwera: Cała „ciężka praca”, czyli dopasowywanie wersji oprogramowania do gigantycznej bazy CVE, odbywa się na menedżerze Wazuha. Hosty końcowe nawet tego nie odczuwają.
Dzięki temu, gdy analitycy Wazuha zaktualizują feed Cyber Threat Intelligence (CTI) o krytyczną podatność (np. wykrytą dzisiaj w nocy w serwerze Apache), Twój menedżer dowie się o niej przy najbliższej synchronizacji (w ciągu 60 minut). Następnie natychmiast przeszuka lokalną bazę danych i wskaże: „Oho, serwer produkcyjny XYZ ma dokładnie tę wersję Apache. Alarm!”.
Zestawienie wszystkich podatności w naszej infrastrukturze możemy wygodnie przeglądać w głównym panelu modułu, który daje świetny, całościowy podgląd sytuacji (widzimy tam m.in. ogólny podział luk według stopnia ich dotkliwości).
Prawdziwą kopalnią wiedzy jest jednak osobny panel inwentaryzacji podatności. To tam możemy wziąć pod lupę każdą podatność z osobna.
Co więcej, po kliknięciu w wybraną podatność otrzymujemy natychmiastowy dostęp do szczegółowych analiz. Wazuh serwuje nam gotowe linki do swojej bazy CTI (Cyber Threat Intelligence) oraz oficjalnych stron vendora (np. Microsoftu, Red Hata czy Canonicala). Administrator nie musi marnować czasu na przeszukiwanie Google w poszukiwaniu instrukcji naprawczych – w jednym miejscu dostaje oficjalne zalecenia, informacje o tym, czy istnieje już oficjalna łata oraz instrukcję, jak krok po kroku zabezpieczyć system.
Tak jak wspomniałem wcześniej, nowo wykryta podatność zostanie automatycznie zgłoszona w głównym panelu SOC Wazuha, z odpowiednim stopniem alertu zależnie od jej krytyczności (severity). Co więcej, jeśli mamy skonfigurowane powiadomienia, system nie czeka, aż ktoś zaloguje się do web UI – zostanie wysłany automatyczny komunikat bezpośrednio do zespołów IT / SOC (np. na maila, Slacka, Teams czy do systemu zgłoszeniowego Jira). Dzięki temu kluczowe osoby dowiadują się o krytycznym zagrożeniu w kilka minut od jego wykrycia.
💡 Perspektywa Compliance: Ten moduł to także gotowa odpowiedź na restrykcyjne wymogi norm takich jak PCI-DSS, ISO 27001 czy unijnej dyrektywy NIS2, które bezwzględnie nakazują organizacjom regularne i udokumentowane zarządzanie podatnościami.
Kontrola Integralności plików (FIM) – oko na kluczowe dane
Mamy już dokładną inwentaryzację naszych systemów i wiemy, na jakie podatności narażone są nasze aplikacje. Czas na mechanizm, który pilnuje, czy nikt nie manipuluje przy kluczowych plikach systemowych i konfiguracyjnych. Wyobraźmy sobie sytuację, w której hakerowi udaje się przełamać zabezpieczenia naszych systemów i dostać do środka. Jego pierwszą myślą będzie prawdopodobnie modyfikacja plików systemowych lub utworzenie nowego użytkownika, aby uzyskać stały dostęp do środowiska. System operacyjny potraktuje taką operację jak zwykłą, legalną edycję plików i w żaden sposób nie zaalarmuje nas, że dzieje się coś złego. I właśnie tutaj do akcji wkracza moduł FIM Wazuha.
Wazuh działa tutaj jak cyfrowy strażnik, który robi dokładne „odciski palców” (skróty kryptograficzne, np. SHA-256) najważniejszych plików w systemie. Samo monitorowanie może odbywać się w dwóch różnych trybach:
- Skanowanie okresowe (scheduled): co określony czas Wazuh sprawdza wybrane foldery i porównuje obecne pliki z bazą wzorcową.
- Monitorowanie w czasie rzeczywistym (real-time): wykorzystując mechanizmy systemowe, Wazuh natychmiast wychwytuje moment, w którym plik został zmodyfikowany, usunięty lub utworzony.
Ścieżki lub pliki w systemie, które chcemy monitorować, możemy wskazać bezpośrednio w konfiguracji ossec.conf na hoście lub rozesłać centralnie poprzez konfigurację grupy. To, który tryb monitorowania wybierzemy, zależy już od naszych konkretnych celów. Co najlepsze, wcale nie musimy się ograniczać – na jednym systemie możemy z powodzeniem stosować oba te podejścia jednocześnie dla różnych ścieżek i katalogów.
<syscheck>
<directories realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories>/bin,/sbin,/boot</directories>
</syscheck>Monitorowanie okresowe sprawdzi się idealnie, jeżeli chcemy zbierać regularne dane audytowe bez obciążania maszyn ciągłą analizą. Z kolei monitorowanie w czasie rzeczywistym to świetny wybór, gdy zależy nam na natychmiastowej reakcji na zagrożenia, musimy jednak pamiętać, że ten tryb nieco mocniej obciąża monitorowane systemy.
W panelu modułu, oprócz głównego dashboardu z podsumowaniem operacji na plikach wykrytych na hostach, możemy też zobaczyć spis wszystkich zdarzeń (eventów) związanych z plikami lub dokładną inwentaryzację monitorowanych plików w ujęciu per host.
💡 Perspektywa Compliance: Kontrola integralności plików to absolutny „święty Graal” dla audytorów. Jest to kluczowy element ISO 27001 oraz wytycznych polskiego KSC2 i europejskiego NIS2, które bezwzględnie nakazują zapewnienie integralności danych i systemów oraz ochronę przed nieautoryzowanymi zmianami.
Wykrywanie zagrożeń i Malware Detection w czasie rzeczywistym
Monitoring zmian w plikach to jedno, ale co w sytuacji, gdy użytkownik pobierze złośliwy załącznik z maila, a na serwerze wyląduje ransomware lub skrypt kopiący kryptowaluty? Tutaj do gry wkracza moduł Malware Detection, który zamienia Wazuha w zaawansowany system detekcji zagrożeń.
Wazuh nie polega na jednej metodzie, zamiast tego buduje wielowarstwową barierę ochronną, której potęga opiera się na korelacji danych z różnych źródeł w celu dokładnej weryfikacji plików:
- Wykrywanie Rootkitów (rootcheck): rozwiązanie dostępne out-of-the-box w platformie. Wazuh regularnie skanuje system w poszukiwaniu głęboko ukrytego złośliwego oprogramowania. Sprawdza m.in. ukryte porty, niewidoczne procesy, modyfikacje tablicy wywołań systemowych oraz pliki, które próbują udawać legalne procesy systemowe.
- Analiza sygnaturowa i integracja z YARA: Wazuh potrafi ściśle współpracować z narzędziem YARA (o którym pisałem w innym artykule). Pozwala to na skanowanie plików pod kątem unikalnych cech, ciągów tekstowych czy wzorców charakterystycznych dla konkretnych rodzin malware. Jeśli plik pasuje do reguły YARA, natychmiast dostajemy alert.
- Integracja z bazami CTI: Gdy agent Wazuha wykryje nowy plik w systemie lub modyfikację istniejącego, może automatycznie wyciągnąć jego hash i odpytać zewnętrzne bazy CTI (np. VirusTotal, które w wersji komercyjnej jest niestety dodatkowo płatne). Jeżeli plik zostanie tam oznaczony jako złośliwy, dowiesz się o tym w kilka sekund.
💡 Perspektywa Compliance: Sam tradycyjny antywirus to dziś za mało, by przejść rygorystyczny audyt. Moduł Malware Detection bezpośrednio realizuje kluczowe wymagania ISO 27001 oraz wytyczne KSC2 (Krajowego Systemu Cyberbezpieczeństwa) w zakresie ciągłego monitorowania bezpieczeństwa i wykrywania anomalii. Co więcej, automatyczna integracja z bazami CTI i YARA idealnie wpisuje się w najnowsze wymogi dyrektywy NIS 2, która kładzie ogromny nacisk na posiadanie mechanizmów wczesnego ostrzegania oraz aktywne zarządzanie podatnościami i zagrożeniami w czasie rzeczywistym.
Security Operations i raportowanie compliance na jeden klik
Ostatnia funkcja, którą omówimy, to absolutne złoto dla osób odpowiedzialnych za bezpieczeństwo i zgodność z przepisami. Mowa o sekcji Security Operations i dashboardach dedykowanych poszczególnym normom – my skupimy się na widoku NIST 800-53.
Jest to niezwykle rygorystyczny zbiór praktyk bezpieczeństwa stworzony przez amerykański Narodowy Instytut Standardów i Technologii. Choć pierwotnie powstał na potrzeby agencji federalnych USA, stał się globalnym wyznacznikiem tego, jak budować dojrzałe systemy ochrony danych. Co ważne dla nas, standard ten opiera się na tych samych głównych zasadach zarządzania ryzykiem i bezpieczeństwa informacji, co europejska dyrektywa NIS 2 oraz polska ustawa o Krajowym Systemie Cyberbezpieczeństwa (KSC2).
Oprócz NIST 800-53 w sekcji tej znajdziemy również osobne dashboardy dla innych kluczowych norm i regulacji, takich jak GDPR (RODO), PCI-DSS czy HIPAA.
W głównym panelu tego widoku możemy znaleźć informacje o najbardziej aktywnych agentach oraz zestawienie Top 10 wymagań danej normy, w które najczęściej wpasowują się zdarzenia wykryte na hostach.
W widoku Controls możemy znaleźć poszczególne wymagania kontrolne normy oraz przypisane do nich wszystkie zdarzenia wykryte przez Wazuha na naszych hostach. Przykładowo wymóg SI.7, mówiący o potrzebie weryfikacji operacji na plikach w celu wykrywania nieautoryzowanych zmian, wyświetli nam precyzyjne zestawienie wszystkich operacji zarejestrowanych na hostach przez opisywany wcześniej moduł FIM.
Jest to nieocenione narzędzie, kiedy chcemy przeprowadzić audyt naszej infrastruktury pod kątem zgodności z normami czy standardami, lub gdy musimy udowodnić audytorowi, że w pełni panujemy nad bezpieczeństwem całego środowiska.
Retencja danych, a wymogi prawne
Warto również wspomnieć, że Wazuh natywnie używa silnika OpenSearch do indeksowania logów zbieranych przez system. Dzięki temu zyskujemy bardzo elastyczne możliwości konfiguracji retencji danych, co stanowi kluczowy wymóg wielu norm i regulacji (często nakazujących przechowywanie logów przez okres od roku do nawet 3 lat). W praktyce audytorskiej to absolutny fundament – podczas weryfikacji możemy zostać poproszeni o odtworzenie szczegółów zdarzenia sprzed kilku miesięcy, zwłaszcza jeśli dotyczyło ono incydentu naruszenia bezpieczeństwa informacji. Nieocenioną rolę odgrywają tu polityki ISM (Index State Management), które pozwalają automatycznie zarządzać cyklem życia logów i dbać o to, by serwery nie zabrakło miejsca na dyskach.
Polityki te możemy skonfigurować bezpośrednio z poziomu web UI platformy Wazuh, przechodząc do zakładki Indexer Management -> Index Management i wybierając opcję Create policy:
Nową politykę najłatwiej skonfigurować przy pomocy edytora JSON (według mnie). Poniżej znajduje się przykładowa polityka retencji danych, która działa globalnie dla wszystkich indeksów w Wazuhu:
{
"policy": {
"description": "Wazuh 4.15.4: hot 4m, cold 8m, delete after 12m",
"default_state": "hot",
"states": [
{
"name": "hot",
"actions": [],
"transitions": [{ "state_name": "cold", "conditions": { "min_index_age": "120d" } }]
},
{
"name": "cold",
"actions": [
{ "read_only": {} },
{ "replica_count": { "number_of_replicas": 0 } }
],
"transitions": [{ "state_name": "delete", "conditions": { "min_index_age": "365d" } }]
},
{
"name": "delete",
"actions": [{ "delete": {} }],
"transitions": []
}
],
"ism_template": [{ "index_patterns": ["wazuh-*"], "priority": 100 }]
}
}Po wklejeniu jej w edytor w GUI klikamy Create i OpenSearch powinien wprowadzić ją w życie. Należy jednak pamiętać, że tak długo przechowywane dane mogą wymagać bardzo dużo przestrzeni dyskowej. Wszystko zależy oczywiście od wielkości naszej infrastruktury, liczby monitorowanych końcówek oraz tego, jak dużo logów realnie generują one każdego dnia. Zanim ustawisz tam konkretną liczbę dni, warto najpierw oszacować średni dzienny przyrost danych.
Przydatne linki:
- Wazuh SIEM/XDR – oficjalna strona produktu, tutaj znajdziesz specyfikację i pełną dokumentację systemu.
- Program Ambasadorów Wazuh – dołącz do społeczności open-source i pomóż nam rozwijać system Wazuh.