SIEM na Elastic Security: pierwsze kroki z regułami
Jak zacząć z SIEM w Elastic Security: źródła logów, gotowe reguły wykrywania, własne reguły i korelacja zdarzeń oraz ograniczanie fałszywych alarmów.
SIEM (Security Information and Event Management) zbiera zdarzenia bezpieczeństwa z całego środowiska, porównuje je z regułami wykrywania i zgłasza alerty, którymi zajmuje się zespół. Elastic Security realizuje to na tym samym Elastic Stack, na którym wiele firm trzyma już logi: dane trafiają do Elasticsearch, reguły działają w silniku wykrywania, a analityk pracuje w Kibanie. Poniżej opisujemy, od czego zacząć, żeby po kilku tygodniach mieć działający system, a nie tysiące alertów, których nikt nie czyta.
Zacznij od pytań, nie od narzędzia
Przed instalacją ustal trzy rzeczy:
- Co chcesz wykrywać. Przejęcie konta, ruch boczny w sieci, nietypowe logowania administratorów, złośliwe oprogramowanie na stacjach? Lista pierwszych scenariuszy powinna zmieścić się na jednej kartce.
- Skąd masz dane. Reguła bez danych nie wykryje niczego. Do wykrywania przejęcia konta potrzebujesz logów uwierzytelniania (Active Directory, Microsoft Entra ID, VPN), do ruchu bocznego logów systemów Windows i firewalli.
- Kto zareaguje na alert. Alert bez właściciela i procedury jest szumem. Ustal, kto go widzi, w jakim czasie reaguje i co robi najpierw. Jeśli nie masz własnego zespołu, który zajmuje się alertami, ustal z dostawcą usługi zakres i czas reakcji.
Krok 1: zbierz dane i ujednolić ich format
Dane do Elastic Security dostarcza Elastic Agent zarządzany z Fleet oraz integracje (np. dla systemów Windows, Linux, firewalli, chmur i usług Microsoft). Integracje zapisują zdarzenia w schemacie ECS (Elastic Common Schema), czyli ze wspólnymi nazwami pól, np. source.ip, user.name, event.action. To ważne, bo jedna reguła może wtedy działać na danych z różnych źródeł.
Dla zdarzeń z endpointów dostępny jest także Elastic Defend, który wykrywa i blokuje złośliwe działania na stacjach i serwerach, a jego alerty trafiają do tego samego widoku co alerty z reguł. Zacznij od źródeł o największej wartości: kontrolerów domeny, firewalla brzegowego, poczty i tożsamości w chmurze. Kolejne dodawaj stopniowo, bo każde to także koszt przechowywania i praca nad dostrojeniem reguł.
Krok 2: włącz gotowe reguły dla tych danych, które masz
Elastic utrzymuje bibliotekę gotowych reguł wykrywania, powiązanych z taktykami i technikami ATT&CK (publiczna baza technik atakujących opracowana przez MITRE). Zainstaluj je i włącz tylko te, dla których masz dane: reguła na logi Windows nie zadziała bez tych logów, a włączona na zapas tylko obciąża klaster. Elastic zaleca zacząć od taktyk, które są dla Ciebie najważniejsze, sprawdzić logikę reguły na danych historycznych przed włączeniem, a potem obserwować stan reguł (czy działają bez błędów) i to, czy faktycznie powstają alerty.
Krok 3: poznaj typy reguł
Elastic Security ma kilka typów reguł i warto wiedzieć, do czego który służy:
| Typ reguły | Do czego służy |
|---|---|
| Custom query | Dopasowanie zdarzeń zapytaniem KQL lub Lucene. Najprostszy i najbardziej elastyczny typ, dobry dla znanych wartości i wzorców. |
| Threshold | Alert, gdy liczba pasujących zdarzeń (grupowanych po polach) przekroczy próg. Pasuje do prób zgadywania haseł. |
| Event correlation (EQL) | Wykrywanie sekwencji zdarzeń w czasie, które mają wspólne pola. To właśnie korelacja: dopiero kilka kroków razem tworzy alert. |
| Indicator match | Porównanie pól zdarzeń z indeksem wskaźników zagrożeń (adresy IP, skróty plików) i wzbogacenie alertu. |
| New terms | Alert, gdy wartość (np. kraj logowania, proces) pojawia się po raz pierwszy w oknie historii. |
| Machine learning | Odchylenia od normalnego zachowania wykryte przez zadania uczenia maszynowego, które trzeba wcześniej utworzyć. |
| ES|QL | Reguły oparte na zapytaniach potokowych, które agregują dane przed alertem. |
Dostępność części funkcji zależy od licencji (subskrypcji) Elastic. Zanim zaplanujesz konkretny typ reguły, sprawdź w dokumentacji Elastic, czy obejmuje go Twoja subskrypcja.
Krok 4: napisz kilka własnych reguł
Gotowe reguły nie znają Twojej firmy. Dla pierwszych własnych reguł wybierz scenariusze, w których kontekst ma znaczenie:
- Próby zgadywania haseł. Reguła threshold: więcej niż określona liczba nieudanych logowań na to samo konto z jednego adresu w krótkim oknie czasu.
- Udane logowanie po porażce. Reguła korelacji EQL, która łączy nieudane i udane uwierzytelnienie tego samego użytkownika w jednym oknie czasu (szkic zapytania pod listą).
- Pierwsze logowanie administratora z nowego kraju. Reguła new terms na polu kraju dla grupy kont uprzywilejowanych.
- Kontakt z listą znanych złośliwych adresów. Reguła indicator match na ruchu z firewalla względem indeksu wskaźników zagrożeń.
Szkic zapytania EQL dla drugiego scenariusza:
sequence by user.name with maxspan=10m
[ authentication where event.outcome == "failure" ]
[ authentication where event.outcome == "success" ]To tylko szkielet. Bez progu liczby porażek i wyłączenia znanych kont usługowych wygeneruje dużo fałszywych alarmów, więc dostrajanie jest częścią pracy.
Każdej regule przypisz poziom ważności, opis i krótką instrukcję, co zrobić po alercie, oraz powiąż ją z techniką ATT&CK. Dzięki temu po kilku miesiącach widać, które obszary są pokryte, a które nie.
Krok 5: ogranicz szum
Najczęstszy powód porzucenia SIEM to nadmiar fałszywych alarmów. Elastic Security ma do tego kilka narzędzi: wyjątki (exceptions), które wyłączają konkretne, znane zachowania z reguły, tłumienie alertów (suppression), które grupuje powtarzające się alerty, oraz wyciszanie (snooze). Zasada: wyjątek dodaje się wąsko (konkretny host i proces), a nie szeroko (cała podsieć). Po pierwszych dwóch tygodniach przejrzyj wszystkie alerty, oceń, które były słuszne, i popraw reguły. Powtarzaj to regularnie, bo środowisko się zmienia.
Krok 6: ustal proces pracy z alertami
W Kibanie alerty trafiają do wspólnego widoku, z którego analityk otwiera szczegóły, buduje oś czasu zdarzeń (Timeline) i zakłada sprawę (case) przypisaną do osoby. Ustal prosty proces: kto przegląda alerty i jak często, jak klasyfikujesz alert (prawdziwy, fałszywy, do obserwacji), kiedy eskalujesz i jak zapisujesz wnioski. Po incydencie dodaj lub popraw regułę, która by go wykryła wcześniej.
Czego SIEM nie zastąpi
SIEM wykrywa, ale nie chroni samodzielnie. Nie zastąpi aktualizacji, kopii zapasowych, uwierzytelniania wieloskładnikowego ani segmentacji sieci. Jest też tylko tak dobry, jak dane i ludzie, którzy na nie patrzą. Dlatego opisany powyżej cykl (dane, reguły, dostrajanie, proces) jest ważniejszy od liczby włączonych reguł.
Zbieranie danych z aplikacji i infrastruktury standardem OpenTelemetry opisujemy w tekście o OpenTelemetry obok Elastic i Grafany. SIEM na Elastic Security, razem z doborem źródeł danych i dostrajaniem reguł, wdrażamy i utrzymujemy w ramach usługi SIEM i bezpieczeństwo.
