Monitoring bezpieczeństwa, IDS/IPS i SIEM

• Rozróżnisz NIDS, HIDS, IDS i IPS oraz ich punkty obserwacji.
• Porównasz wykrywanie sygnaturowe z wykrywaniem anomalii względem baseline.
• Wyjaśnisz rolę centralnego logowania, Syslog i SIEM.
• Przeprowadzisz siedmioetapowy proces od zdarzenia do udokumentowanej decyzji.
• Ocenisz priorytet alertu, false positive, false negative i ograniczenia telemetrii.

Wymagania wstępne

• Monitoring i zarządzanie siecią
• TCP, UDP i porty
• Analiza pakietów w Wiresharku
• Zagrożenia i ochrona sieci

Nazwy produktów bywają marketingowo łączone jako IDPS, NDR lub EDR. O rzeczywistej roli decyduje punkt obserwacji, dane wejściowe i możliwość egzekwowania decyzji. IDS nie staje się IPS tylko dlatego, że wysyła alert do administratora.

Baseline powinien rozróżniać dni robocze, kopie nocne, aktualizacje, pracę zdalną i sezonowość. Uczenie profilu podczas awarii lub incydentu może utrwalić zły wzorzec jako normalny.

Centralne logowanie przenosi kopie zdarzeń poza system źródłowy, ułatwia wspólną retencję i chronologię. Syslog opisuje format oraz role nadawcy, przekaźnika i kolektora; wybór transportu wpływa na poufność i pewność dostarczenia. Samo wysłanie przez UDP nie gwarantuje odbioru ani ochrony treści.

SIEM (Security Information and Event Management) gromadzi, normalizuje, wyszukuje i koreluje dane z wielu źródeł. Reguła korelacji tworzy alert, ale nie zastępuje analityka, danych źródłowych i procesu reagowania.

O 08:57 użytkownik trzy razy myli hasło do VPN. O 09:02 loguje się poprawnie z nowego adresu, o 09:05 jego komputer pyta DNS o rzadko używaną domenę, a o 09:07 firewall rejestruje krótkie połączenie HTTPS. Każdy zapis może być normalny: literówka, praca z hotelu, nowa usługa producenta i zwykły HTTPS.

Razem zdarzenia wymagają triage, ponieważ dotyczą tej samej tożsamości i krótkiego przedziału czasu. Analityk sprawdza MFA, reputację i własność urządzenia, proces inicjujący DNS, zatwierdzone zmiany oraz treść dostępnych logów. Bez tych danych nie przesądza o przejęciu konta.

• Oceń wiarygodność reguły i kompletność źródeł, a nie tylko nazwę alertu.
• Uwzględnij krytyczność aktywa, uprawnienia konta, ekspozycję i możliwy wpływ.
• Sprawdź, czy zdarzenie trwa i czy szybkie ograniczenie zmniejszy ryzyko bez utraty dowodów.
• Zapisz alternatywne hipotezy, dane potwierdzające i dane przeczące.
• Nadaj właściciela, termin następnego kroku i kanał eskalacji.

False positive to alarm dotyczący działania, które po analizie nie jest naruszeniem wymagającym reakcji. False negative oznacza, że istotne zdarzenie nie zostało wykryte. Oba zjawiska są nieuniknione: zbyt szeroka reguła obciąża analityków, a zbyt wąska pozostawia luki.

Strojenie reguły powinno zachować przykłady, datę, właściciela i możliwość wycofania. Wyjątek dla jednego legalnego procesu nie powinien wyciszyć wszystkich zdarzeń danego typu. Skuteczność mierzy się m.in. czasem obsługi, jakością eskalacji, pokryciem źródeł i wykryciami z ćwiczeń kontrolnych.

• Szyfrowanie ogranicza treść widoczną dla NIDS, ale nadal mogą być dostępne metadane i telemetria końcówki.
• SPAN może gubić pakiety pod obciążeniem; sensor nie powinien zakładać pełnej kopii ruchu.
• Brak logu może oznaczać brak zdarzenia, błąd źródła, utratę transportu albo koniec retencji.
• Priorytet alertu powinien łączyć pewność detekcji i wpływ, a nie tylko liczbę trafień.
• Automatyczne blokowanie wymaga progów, wyjątków, monitoringu skutku i procedury cofnięcia.

• Traktowanie SIEM jako magazynu bez właścicieli źródeł i reguł.
• Uznanie alertu IDS za dowód i automatyczne zablokowanie współdzielonego adresu.
• Normalizacja usuwająca pola potrzebne do późniejszej analizy bez zachowania oryginału.
• Brak monitoringu opóźnienia, utraty i pojemności samego systemu logowania.
• Retencja ustalona przypadkowo, bez wymagań dochodzeniowych i minimalizacji danych.

• Dlaczego NIDS i HIDS mogą dojść do różnych, ale zgodnych obserwacji?
• W jakiej sytuacji reguła anomalii może mieć dużo false positive?
• Co odróżnia etap korelacji od triage alertu?
• Dlaczego IDS nie powinien być opisywany jako narzędzie automatycznie blokujące?
• Jak synchronizacja czasu i integralność logów wpływają na chronologię incydentu?

Zaprojektuj dla fikcyjnej firmy pięć źródeł logów, pola niezbędne do korelacji, okres retencji oraz właściciela. Następnie opisz regułę łączącą logowanie VPN, DNS i firewall, wraz z dwiema hipotezami legalnymi, kryterium eskalacji oraz możliwością wycofania automatycznej blokady.

1. Uporządkuj siedem kroków obsługi alertu i wskaż, które artefakty trzeba zachować w oryginalnej postaci.
2. Dla przykładu z VPN, DNS i HTTPS przygotuj tabelę czasu, wspólnych identyfikatorów, danych potwierdzających i alternatywnych wyjaśnień.
3. Zaproponuj jeden test kontrolny wykrywający utratę logów oraz jedną metrykę jakości triage.

• NIDS, HIDS, IDS i IPS różnią się punktem obserwacji oraz możliwością działania.
• Sygnatury, anomalie i baseline uzupełniają się, lecz generują false positive i false negative.
• SIEM łączy dane, ale wiarygodny wniosek wymaga triage, kontekstu aktywa i zachowania źródeł.
• Czas, retencja, integralność i dostępność logów są częścią systemu detekcji.

• Monitoring i zarządzanie
• Analiza pakietów w Wiresharku
• Zagrożenia i ochrona sieci
• Reagowanie na incydenty
• CYB-02 — Analiza anomalii w Wiresharku
• CYB-05 — Korelacja logów i podstawy SIEM
• CYB-06 — Zabezpieczanie materiału: logi i PCAP

• NIST SP 800-94 — Guide to Intrusion Detection and Prevention Systems
• NIST — Log Management Project
• RFC 5424 — The Syslog Protocol
• NIST SP 800-61 Rev. 3 — Incident Response