Pisanie reguł detekcji i korelacja
Utworzą Państwo zapytania Splunk SPL lub Kibana KQL wykrywające ataki brute force, ruch boczny i eksfiltrację danych.
Pisanie reguł detekcji i korelacja to bezpłatna lekcja Cyber Security Academy na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cyber Security Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.
Podstawy projektowania mechanizmów wykrywania
Reguły wykrywania przekładają zachowania napastników na logikę zapytań, która uruchamia się po pojawieniu się danego wzorca w logach. Dobrze zaprojektowane mechanizmy wykrywania są wystarczająco szczegółowe, aby ograniczać liczbę fałszywych alarmów, ale jednocześnie wystarczająco szerokie, aby wykrywać różne warianty ataku.
SPL w Splunk: Search Processing Language
Zapytania SPL używają składni potokowej: wyszukiwanie → transformacja → wyświetlanie. Należy rozpocząć od określenia indeksu i sourcetype, odfiltrować odpowiednie zdarzenia, a następnie zagregować wyniki lub wygenerować na ich podstawie alert.
# Basic SPL structure
index=security sourcetype=WinEventLog EventCode=4625
| stats count by src_ip, user
| where count > 10
| sort -count
# Explanation:
# Search Security index for logon failures
# Count failures per source IP + user
# Alert if more than 10 failures
# Sort descending by countWykrywanie ataków brute force w Splunk
Wykrywanie ataków brute force polega na zliczaniu nieudanych logowań z poszczególnych źródeł i generowaniu alertu po przekroczeniu progu w określonym przedziale czasu. Wykrywanie credential stuffing wymaga skorelowania nieudanych logowań z udanym logowaniem następującym po tych próbach.
# Failed logins by source IP
index=security EventCode=4625
| bucket _time span=5m
| stats count as failures by _time, src_ip
| where failures > 20
| table _time, src_ip, failures
# Success after failures (account takeover)
index=security EventCode=4625 OR EventCode=4624
| stats values(EventCode) as events by src_ip
| where mvfind(events,"4625") >= 0 AND mvfind(events,"4624") >= 0KQL w Kibana na potrzeby wykrywania
Kibana Query Language (KQL) filtruje zdarzenia na potrzeby dochodzeń. Jest czytelniejszy dla analityków niż Lucene; należy używać go w zapisanych wyszukiwaniach i regułach alertów w Kibana.
# KQL examples:
# Failed SSH logins
event.action: "ssh_login_failed" and source.ip: *
# Nmap scan detection
not destination.port: (80 or 443 or 22) and event.type: "connection"
# Privilege escalation
process.name: "sudo" and process.args: "-s"Reguły wykrywania w Elasticsearch
Aplikacja Security w Kibana zawiera silnik reguł wykrywania. Reguły mogą być oparte na progach (liczba zdarzeń), zapytaniach (konkretny wzorzec zdarzenia), anomaliach wykrywanych przez ML lub sekwencjach EQL (Event Query Language).
# EQL sequence rule example (Kibana Security):
sequence by host.name
[process where process.name == "cmd.exe"]
[network where destination.port == 4444]
# Detects: cmd.exe followed by connection to port 4444
# (common reverse shell pattern)Wykrywanie ruchu lateralnego
Ruch lateralny można wykrywać na podstawie: utworzenia usługi PsExec (zdarzenie 7045), zdalnego wykonania za pomocą WMI, nietypowego dostępu do udziałów administracyjnych (zdarzenie 5140) oraz nowych zaplanowanych zadań tworzonych zdalnie.
# Splunk: detect PsExec-style lateral movement
index=security EventCode=7045
| where Service_Name="PSEXESVC" OR Service_File_Name="\\*\\*.exe"
| table _time, ComputerName, Service_Name, Service_File_Name
# WMI remote execution
index=sysmon EventCode=1 ParentImage="*WmiPrvSE.exe"
| table _time, host, CommandLine, UserWykrywanie eksfiltracji danych
Eksfiltrację można wykrywać na podstawie: dużych transferów wychodzących do nietypowych miejsc docelowych, zapytań DNS z nienormalnie długimi subdomenami (tunelowanie) oraz komunikacji beaconingowej HTTPS w regularnych odstępach.
# DNS tunneling detection in Splunk
index=dns
| eval subdomain_len=len(subdomain)
| where subdomain_len > 50
| stats count by query, src_ip
| sort -count
# Large outbound (NetFlow/firewall logs)
index=firewall action=allow direction=outbound
| stats sum(bytes) as total_bytes by dest_ip, src_ip
| where total_bytes > 100000000 # 100MB thresholdThreat hunting za pomocą zapisanych wyszukiwań
Często używane zapytania wykrywające należy zapisywać jako zaplanowane wyszukiwania, które wysyłają wiadomości e-mail lub tworzą incydenty. Należy ustawić odpowiednie przedziały czasu i progi, aby znaleźć równowagę między szybkością wykrywania a odsetkiem fałszywych alarmów.
Wykrywanie mapowane na MITRE ATT&CK
Reguły wykrywania należy mapować na techniki ATT&CK. Pozwala to wskazać luki w pokryciu i ustalić priorytety dla nowych reguł. Narzędzia takie jak ATT&CK Navigator wizualizują, które techniki są wykrywane, a które pozostają niewidoczne.
Dostrajanie w celu ograniczenia liczby fałszywych alarmów
Nowe reguły często działają zbyt szeroko. Należy je dostrajać poprzez: dodawanie wykluczeń dla znanych, prawidłowych źródeł, podnoszenie progów, dodawanie pól kontekstowych (godziny pracy, znane adresy IP skanerów) oraz weryfikację względem danych historycznych przed aktywacją.
Zmęczenie alertami
Zbyt duża liczba alertów niskiej jakości powoduje, że analitycy zaczynają je ignorować, niwecząc cel całego mechanizmu. Jakość należy stawiać wyżej niż ilość: 10 alertów o wysokiej wiarygodności dziennie jest lepsze niż 500 zaszumionych. Należy wyciszać, dostrajać i wycofywać nieskuteczne reguły.
Szybkie sprawdzenie
Co wykrywa reguła sekwencji EQL, czego nie może wykryć prosta reguła oparta na zapytaniu?
Podsumowanie: reguły wykrywania
Projektowanie mechanizmów wykrywania przekształca TTP napastników w logikę zapytań. W Splunk należy używać SPL, a w Kibana Security — KQL i EQL. Reguły należy mapować na MITRE ATT&CK, aby śledzić zakres pokrycia. Należy preferować precyzyjne, ukierunkowane reguły zamiast szerokich i generujących szum. Trzeba je stale dostrajać — krajobraz zagrożeń się zmienia, więc logika wykrywania również powinna się zmieniać.
Często zadawane pytania
Czy lekcja „Pisanie reguł detekcji i korelacja” jest bezpłatna?
Tak — pełny tekst „Pisanie reguł detekcji i korelacja” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cyber Security Academy, przejdź na CoddyKit PRO. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.
Co nauczysz się w „Pisanie reguł detekcji i korelacja”?
Utworzą Państwo zapytania Splunk SPL lub Kibana KQL wykrywające ataki brute force, ruch boczny i eksfiltrację danych. Ćwiczysz Cyber Security Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć Cyber Security Academy?
Nie wymagamy żadnego doświadczenia. Cyber Security Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.
Ile czasu zajmuje lekcja „Pisanie reguł detekcji i korelacja”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji Cyber Security Academy?
Tak. Każda lekcja Cyber Security Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Źródła logów: systemowe, sieciowe i aplikacyjne
- Architektura SIEM i pobieranie logów
- Pisanie reguł detekcji i korelacja
- Triaging alertów i przebieg pracy SOC