System SIEM zbiera zdarzenia z różnych systemów, porządkuje je i pomaga wykrywać sytuacje wymagające sprawdzenia. Dla kierownictwa jego wartość można opisać prosto: organizacja szybciej otrzymuje informacje o tym, co się dzieje, których usług może dotyczyć problem i kto powinien zareagować.
Sama instalacja oprogramowania jest początkiem. Skuteczny monitoring wymaga właściwych danych, reguł, osoby analizującej alarm oraz upoważnień do dalszego działania. Przed zakupem usługi warto zrozumieć cały ten proces.
Jak działa SIEM na prostym przykładzie
Przyjmijmy modelową sytuację. Konto pracownika loguje się z nowego adresu IP. Niedługo potem pojawia się zmiana uprawnień lub nietypowa operacja w aplikacji. Każdy system rejestruje własny fragment historii.
SIEM może zebrać te informacje i zastosować przygotowaną regułę. Powstaje alert, czyli sygnał wymagający oceny. Analityk sprawdza kontekst: czy pracownik podróżuje, korzysta z firmowego VPN, wykonywał zatwierdzoną zmianę albo zgłaszał problem z dostępem.
Po analizie sprawa może zostać uznana za dozwolone działanie, błąd konfiguracji albo incydent. Dopiero wtedy podejmuje się uzgodnione czynności, na przykład dodatkową weryfikację konta, ograniczenie sesji lub kontakt z właścicielem usługi. Zakres automatyzacji zależy od przygotowanej integracji i upoważnień.
Przepływ wygląda następująco: źródło zdarzenia → odbiór i rozpoznanie danych → reguła → alert → analiza → działanie → sprawdzenie rezultatu.
Jakie dane powinny wpływać do SIEM
Listę źródeł należy powiązać z pytaniami, na które organizacja chce odpowiadać. Zbieranie wszystkiego bez określonego celu utrudnia analizę i zwiększa koszty przechowywania.
| Źródło | Przykładowa informacja | Do czego może się przydać |
|---|---|---|
| Windows i Linux | Logowania, zmiany kont, wybrane zdarzenia systemowe | Weryfikacja dostępu i działań administracyjnych |
| Ochrona urządzeń | Wykrycie zagrożenia, stan ochrony | Ocena problemu na konkretnej stacji |
| Firewall i VPN | Połączenia, blokady, sesje zdalne | Ustalenie drogi dostępu i ruchu sieciowego |
| Microsoft 365 i Entra ID | Dostępne zdarzenia audytu i logowania | Analiza kont i działań w chmurze |
| System kopii | Wynik zadania, błąd, brak oczekiwanego wykonania | Wykrycie przerwy w ochronie danych |
| Skaner podatności | Wynik skanu i identyfikator zasobu | Ustalenie kontekstu dla podatnego systemu |
Wazuh wspiera różne sposoby zbierania danych, m.in. agentów, analizę plików dzienników i obsługę określonych integracji. Konkretne możliwości zależą od konfiguracji i źródła. Dostęp przez API nie gwarantuje, że produkt udostępnia wszystkie potrzebne zdarzenia. Dokumentacja zbierania logów Wazuh.
Log, alert i incydent oznaczają różne rzeczy
Log to zapis zdarzenia. Alert powstaje, gdy reguła wskazuje warunek wymagający uwagi. Incydent jest ocenianą sytuacją mającą lub mogącą mieć niekorzystny wpływ na bezpieczeństwo. Jedna sprawa może obejmować wiele alertów i tysiące zapisów źródłowych.
Dlatego liczba alarmów nie jest samodzielną miarą jakości ochrony. Po zmianie reguł może spaść liczba powtarzających się powiadomień, choć zakres monitoringu się poprawił. Może też spaść dlatego, że przestały napływać dane. Raport musi wyjaśniać przyczynę.
Także wysoki poziom alarmu w produkcie nie przesądza o prawnej kwalifikacji incydentu. Osoba prowadząca sprawę ocenia wpływ, zakres i właściwe kryteria zgłoszenia. SIEM dostarcza materiał do tej oceny.
Jak system interpretuje zdarzenia
Najpierw trzeba prawidłowo rozpoznać pola: czas, urządzenie, użytkownika, rodzaj działania, wynik i adresy sieciowe. Jeżeli eksport nie rozróżnia udanego logowania od nieudanej próby, reguła może prowadzić do błędnego wniosku.
Następnie dochodzi kontekst organizacji. Konto techniczne ma inny typowy sposób użycia niż konto pracownika księgowości. Serwer udostępniający usługę publicznie wymaga innej oceny niż urządzenie w odseparowanej sieci. Właściciel zasobu i znaczenie usługi pomagają ustalić priorytet.
Na końcu regułę trzeba przetestować. Przykładowy test może polegać na wykonaniu uzgodnionej operacji na koncie testowym, odnalezieniu jej w źródle i sprawdzeniu, czy dotarła do właściwego widoku. Próba powinna mieć identyfikator, czas oraz oczekiwany rezultat. To pozwala odróżnić działającą integrację od samej deklaracji w konfiguracji.
Co powinien widzieć administrator, a co zarząd
Administrator potrzebuje szczegółów: źródła, reguły, urządzenia, czasu, pól zdarzenia i powiązanych zapisów. Powinien również widzieć stan integracji, opóźnienia oraz błędy pobierania przez API.
Zarząd potrzebuje odpowiedzi na inne pytania: czy ważne usługi są objęte obserwacją, co wymaga działania, jaki jest skutek biznesowy i gdzie konieczna jest decyzja. Dobry raport zawiera także braki danych oraz zadania oczekujące na wykonanie po stronie organizacji.
Na przykład informacja „97 z 100 urządzeń przekazało dane w oczekiwanym czasie” jest bardziej użyteczna niż zielony wskaźnik bez opisu. Pozostałe trzy urządzenia trzeba rozpoznać: mogą być wyłączone zgodnie z harmonogramem albo utracić połączenie z monitoringiem.
Kto reaguje na alarm i w jakich godzinach
Automatyczne zbieranie zdarzeń może działać przez całą dobę. Obsługa przez człowieka ma własny harmonogram. Przy wyborze usługi ustal osobno czas zbierania danych, częstotliwość przeglądu, kanał alarmowania i warunki reakcji poza godzinami pracy.
Automatyczne zbieranie danych i przegląd przez analityka to osobne parametry. W pakiecie Stała opieka + SIEM przegląd odbywa się raz w tygodniu, a w Rozszerzonej opiece + SIEM w każdy dzień roboczy. Okno kontaktu to poniedziałek–piątek 8:00–16:00, z wyłączeniem świąt; nie oznacza ciągłego dyżuru ani gwarantowanego czasu reakcji. Reakcję poza tym oknem oraz prace naprawcze uzgadnia się osobno. Aktualny zakres i odpowiedzialność DataOne.
Co wpływa na koszt utrzymania SIEM
Liczba urządzeń jest tylko jednym z parametrów. Duże znaczenie mają ilość zdarzeń, liczba integracji, potrzebne reguły, czas przechowywania oraz praca analityków i administratorów.
Oddziel okres szybkiego wyszukiwania od całkowitego przechowywania logów. Archiwum musi pozwalać odzyskać potrzebne dane, z zachowaniem kontroli dostępu i integralności. Retencję ustala się według zastosowania, umów i właściwych przepisów; nie wynika ona wyłącznie z domyślnych ustawień produktu.
Uwzględnij też utrzymanie samego SIEM: aktualizacje, kopie konfiguracji, test odtworzenia, certyfikaty i nadzór nad zajętością dysku. Awaria narzędzia obserwującego środowisko powinna zostać zauważona przez niezależny mechanizm.
Jak rozpocząć wdrożenie bez niepotrzebnego rozbudowania projektu
Wybierz kilka ważnych scenariuszy, na przykład podejrzane użycie konta, alarm ochrony urządzenia i przerwę w napływie danych. Podłącz reprezentatywne źródła i sprawdź cały przebieg sprawy. Dopiero na tej podstawie rozszerzaj zakres.
Jeżeli chcesz ocenić, czy SIEM będzie przydatny w Twoim środowisku, porozmawiaj z DataOne o pilotażu monitoringu. Ustalimy źródła, scenariusze i kryteria odbioru. Otrzymasz podstawę do decyzji o zakresie ochrony, opartą na danych z Twojej organizacji i wynikach uzgodnionych testów.