01 - Inżynieria wykrywania: od dyscypliny, przez skrypt, po potok
W stale rozwijającym się krajobrazie zagrożeń cybernetycznych możliwość wykryć złośliwa aktywność, zanim spowoduje znaczne szkody, stanowi prawdziwą różnicę między organizacją odporną i wrażliwą. Od dziesięcioleci wykrywanie zagrożeń zajmuje się wykrywaniem zagrożeń powierzone doraźnym pisemnym zasadom, sygnaturom antywirusowym i indywidualnej intuicji analityków SOC. Dzisiaj, to rzemieślnicze podejście nie jest już zrównoważone: ilość kłód, złożoność Infrastruktura natywna dla chmury i zaawansowanie atakujących wymagają odpowiedniego podejścia inżynieryjne i systematyczne.
Tak to się narodziło Inżynieria wykrywania: dyscyplina, która stosuje zasady inżynierii oprogramowania po proces tworzenia, testowania, wdrażania i utrzymywania oprogramowania zasady wykrywania. Nie chodzi już o pisanie izolowanych zapytań w SIEM, chodzi o budowanie zautomatyzowane rurociągi, wersjonuj wykrycia jako kod i przetestuj je za pomocą danych symulowane i mierzyć je za pomocą obiektywnych wskaźników.
Czego dowiesz się w tym artykule
- Czym jest inżynieria wykrywania i dlaczego stała się dyscypliną autonomiczną
- Ewolucja od skryptów ad hoc do potoków CI/CD do wykrywania
- Pełny cykl życia detekcji: hipoteza, rozwój, test, wdrożenie, strojenie
- Główne rodzaje detekcji: oparta na sygnaturach, behawioralna, oparta na anomaliach
- Wskaźniki jakości: współczynnik prawdziwie dodatni, współczynnik fałszywie dodatni, MTTD, MTTR
- Ekosystem SIEM/SOAR i kluczowe źródła danych
- Koncepcja potoków wykrywania jako kodu i CI/CD dla reguł bezpieczeństwa
- Praktyczne przykłady z regułami Sigma, skryptami Pythona i konfiguracjami YAML
Co to jest inżynieria wykrywania
La Inżynieria wykrywania oraz systematyczny proces projektowania, rozwoju, testowanie i konserwacja logiki identyfikującej złośliwą aktywność w ramach telemetrii organizacji. Ta telemetria obejmuje logi z punktów końcowych, infrastruktury chmurowej, dostawcy tożsamości, aplikacje internetowe, systemy sieciowe i wiele innych.
W przeciwieństwie do tradycyjnego podejścia, gdzie analityk SOC zapisuje zapytanie do SIEM w odpowiedzi na konkretny incydent Detection Engineering przyjmuje: przepływ pracy zorganizowany przypominające współczesne tworzenie oprogramowania: wersjonowanie kodu, przeglądanie kodu, automatyczne testowanie, ciągłe wdrażanie i monitorowanie wydajności na produkcji.
„Inżynieria wykrywania jest dla SOC tym, czym inżynieria oprogramowania dla kodowania: przekształca doraźne, aktywność reaktywną w systematyczną, mierzalną i stale doskonalącą się dyscyplinę.”
- Instytut SANS, Badanie dotyczące inżynierii wykrywania 2025
Trzy filary inżynierii wykrywania
Dyscyplina opiera się na trzech wzajemnie powiązanych filarach, które określają jej dojrzałość:
- Analiza zagrożeń - Zrozum, kim są przeciwnicy, jakich technik używają (MITRE ATT&CK) oraz jakie aktywa organizacji są zagrożone. Bez zrozumienia głębokości zagrożeń, wykrycia będą ogólne i niezbyt skuteczne.
- Inżynieria danych - Zapewnij gromadzenie i normalizację niezbędnych dzienników i dostępne do analizy. Idealne i bezużyteczne wykrywanie, jeśli dane, na których działa, nie są obecne lub są złej jakości.
- Inżynieria oprogramowania - Zastosuj najlepsze praktyki tworzenia oprogramowania: kontrola wersji, testowanie, CI/CD, dokumentacja, metryki. Wykrycia należy leczyć jako kod produkcyjny.
Ewolucja: od skryptów ad hoc do dyscypliny inżynierskiej
Ścieżkę, która doprowadziła do nowoczesnej Inżynierii Detekcyjnej można podzielić na cztery odrębne fazy, z których każda charakteryzuje się rosnącym poziomem dojrzałości i automatyzacji.
Faza 1: Era podpisów (1990-2005)
Wczesne formy wykrywania opierały się na podpisy statyczne: znane wzorce złośliwe oprogramowanie, skróty złośliwych plików, określone ciągi w ładunkach sieciowych. Każdy program antywirusowy i IDS (Intrusion Detection System) utrzymywał bazę sygnatur, która była okresowo aktualizowana. Podejście to sprawdzało się dość dobrze w przypadku znanych zagrożeń, ale było całkowicie ślepe na zagrożenia do nowych odmian lub niestandardowych ataków.
Faza 2: Wiek skryptów SIEM (2005-2015)
Wraz z rozprzestrzenianiem się pierwszego SIEM (Informacje dotyczące bezpieczeństwa i zarządzanie wydarzeniami), analitycy zaczęli pisać niestandardowe zapytania i korelacje. Każdy analityk miał własne podejście, własne skrypty, własne konwencje nazewnictwa. Powstały zasady bezpośrednio w interfejsie sieciowym SIEM, bez wersjonowania, bez testowania, bez dokumentacji standaryzowane. Kiedy analityk opuszczał organizację, często pojawiały się jego wykrycia niezrozumiałe dla następców.
Faza 3: Narodziny inżynierii detekcyjnej (2015–2022)
W latach 2015–2022 społeczność zajmująca się bezpieczeństwem zacznie dostrzegać potrzebę: bardziej zorganizowane podejście. Rodzą się standardowe formaty, takie jak Sigmy (2017) za zasady wykrywania, ramy AT&CK UKOŚNIENIA staje się punktem odniesienia uniwersalne do mapowania technik przeciwników i pierwsze dedykowane zespoły Detekcyjne Inżynieria pojawia się w bardziej dojrzałych organizacjach.
Faza 4: Wykrywanie jako kod i potok CI/CD (od 2022 r.)
Obecnie najbardziej zaawansowane organizacje traktują wykrycia dokładnie tak, jak kod oprogramowania. Reguły są pisane w formatach deklaratywnych (Sigma, YAML), wersjonowane w repozytoriach Git, automatycznie testowane na symulowanych danych, wdrażane za pośrednictwem potoku CI/CD i monitorowane z dedykowanymi dashboardami. Według Ankieta dotycząca inżynierii wykrywania SANS 2025, 60% organizacji utrzymuje dedykowane zespoły ds. inżynierii wykrywania, a 70% przedsiębiorstw zatrudniających powyżej 5000 pracowników, które utworzyły już ustrukturyzowane zespoły.
| Faza | Okres | Zbliżać się | Instrumenty | Limity |
|---|---|---|---|---|
| Podpisy statyczne | 1990-2005 | Dopasowywanie wzorców do znanych podpisów | Antywirus, IDS (Snort) | Niewidoczne dni zerowe, duże opóźnienia |
| Skrypty SIEM-a | 2005-2015 | Zapytania ad hoc w SIEM | Splunk, ArcSight, QRadar | Niewersjonowana, nieprzetestowana, wiedza zaszyfrowana |
| Inżynieria wykrywania | 2015-2022 | Ustrukturyzowany przepływ pracy ze standardami | Sigma, ATT&CK, ELK | Wciąż dużo ręcznych procesów |
| Wykrywanie jako kod | 2022-obecnie | Potok CI/CD, wszystkie wersje | Git, CI/CD, Sigma, SOAR | Wymaga dojrzałości organizacyjnej |
Cykl życia wykrycia
Każde wykrycie ma ściśle określony cykl życia, który gwarantuje jakość, skuteczność i łatwość konserwacji w czasie. Cykl składa się z sześciu podstawowych faz, każda z wyników i szczegółowych kryteriów jakości.
1. Hipoteza (Hipoteza)
Wszystko zaczyna się od jednego hipoteza zagrożenia. Analityk lub inżynier ds. wykrywania identyfikuje konkretną technikę ataku (np. „Napastnik mógłby się przydać PowerShell do pobierania i wykonywania złośliwych ładunków”) i sformułuj hipotezę na temat tego, w jaki sposób działanie to będzie widoczne w dostępnych logach. Źródła hipotez obejmują:
- Analiza zagrożeń - Raport na temat aktywnych kampanii, zaobserwowanych TTP
- AT&CK UKOŚNIENIA - Techniki przyporządkowane konkretnym taktykom
- Wypadek pośmiertny - Wnioski wyciągnięte z poprzednich incydentów
- Ustalenia zespołu Czerwonego - Wyniki testów penetracyjnych i fioletowego teamingu
- Analiza luk - Techniki ATT&CK bez zasięgu detekcji
2. Rozwój (Rozwój)
Po zdefiniowaniu hipotezy inżynier detekcji pisze regułę detekcji. To wiąże się z wyborem formatu (Sigma, natywne zapytanie SIEM, skrypt Python), definicji niezbędnych logów źródłowych, logiki selekcji i filtrowania oraz dokumentacji pliku metadane (autor, istotność, mapowanie ATT&CK, znane fałszywe alarmy).
3. Testowanie i walidacja (testowanie)
Przed wdrożeniem wykrycie należy zweryfikować w oparciu o dane rzeczywiste i symulowane. Testowanie obejmuje: prawdziwie pozytywne testy (czy reguła wykrywa symulowany atak?), fałszywie pozytywne testy (czy reguła generuje alerty o legalnych działaniach?), e testowanie wydajności (reguła jest wystarczająco skuteczna w przypadku woluminów dziennik produkcji?).
4. Wdrożenie
Wdrożenie odbywa się za pośrednictwem zautomatyzowanych potoków, które konwertują regułę na format natywny dla docelowego SIEM, wdróż go na środowisko produkcyjne i zweryfikuj jego poprawność operacja. W dojrzałych środowiskach proces ten jest w pełni zautomatyzowany poprzez CI/CD.
5. Monitorowanie i metryki
Po rozpoczęciu produkcji wykrywanie jest stale monitorowane. Kluczowe wskaźniki obejmują liczbę wygenerowanych alertów, stosunek wartości dodatnich do fałszywych, średni czas wykrywanie (MTTD) i wpływ na obciążenie analityka SOC.
6. Strojenie i konserwacja
Na podstawie danych zebranych podczas produkcji wykrywanie jest stale udoskonalane. The dostrajanie może obejmować dodanie wyjątków dla powtarzających się fałszywych alarmów, poszerzenie logiki, aby objąć odmiany techniki lub wycofanie reguły, jeśli nie więcej istotne.
Najlepsza praktyka: Fioletowe łączenie drużyn
Il fioletowy zespół znacznie przyspiesza pętlę sprzężenia zwrotnego cykl życia wykrywania. Łączenie umiejętności ofensywnych Drużyny Czerwonych z defensywnymi Blue Team, możliwa jest symulacja rzeczywistych technik ataku i walidacja wykryć czasie rzeczywistym, skracając czas między hipotezą a potwierdzonym wykryciem z tygodni do godzin.
Rodzaje wykrywania: od IOC do zachowania
Wykrycia można klasyfikować w oparciu o zastosowaną logikę wykrywania. Każdy typ ma określone zalety i ograniczenia, a dojrzały program wykrywania łączy je wszystko w sposób warstwowy.
1. Wykrywanie oparte na sygnaturach
Wyszukiwanie oparte na sygnaturach dokładne wzory w danych: skrót pliku znane, określone ciągi w poleceniach, adresy IP lub znane złośliwe domeny (IOC – Indicators Kompromisu). Jest to najprostszy i najszybszy typ, z bardzo niskim współczynnikiem wyników fałszywie dodatnich, ale całkowicie nieskuteczne wobec nowych lub wariantowych zagrożeń.
title: Emotet Loader Hash Detection
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: stable
description: Detects known Emotet loader by file hash
author: Detection Engineering Team
date: 2025/10/15
references:
- https://attack.mitre.org/software/S0367/
logsource:
category: file_event
product: windows
detection:
selection:
Hashes|contains:
- 'SHA256=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'
- 'SHA256=a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a'
- 'MD5=d41d8cd98f00b204e9800998ecf8427e'
condition: selection
falsepositives:
- Unlikely, known malicious hashes
level: critical
tags:
- attack.execution
- attack.t1204.0022. Wykrywanie zachowań
Poszukiwane są detekcje behawioralne sekwencje akcji lub wzór zachowania wskazujące na podejrzaną aktywność, niezależnie od konkretnych IOC. Na przykład zamiast szukać konkretnego skrótu Mimikatza, wykrywanie behawioralne może szukać dowolnego procesu uzyskującego dostęp do pamięci LSASS w celu wyodrębnienia poświadczeń. Takie podejście jest znacznie bardziej odporne na uniki, ponieważ atakujący mogą się zmieniać własne narzędzia, ale prawie nie mogą zmienić podstawowej techniki.
title: Suspicious LSASS Process Access - Credential Dumping
id: b2c3d4e5-f6a7-8901-bcde-f12345678901
status: experimental
description: |
Detects process access to LSASS memory, a common technique
for credential dumping (T1003.001). Focuses on behavior
rather than specific tool signatures.
author: Federico Calo
date: 2025/11/20
references:
- https://attack.mitre.org/techniques/T1003/001/
logsource:
category: process_access
product: windows
detection:
selection:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010' # PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ
- '0x1038' # Read memory access
- '0x1FFFFF' # PROCESS_ALL_ACCESS
filter_legitimate:
SourceImage|endswith:
- '\MsMpEng.exe' # Windows Defender
- '\csrss.exe' # Client Server Runtime
- '\wmiprvse.exe' # WMI Provider
- '\svchost.exe' # Service Host
filter_system:
SourceUser|contains: 'SYSTEM'
SourceImage|startswith: 'C:\Windows\System32\'
condition: selection and not filter_legitimate and not filter_system
falsepositives:
- Legitimate security tools performing memory scanning
- EDR solutions with high-privilege access
level: high
tags:
- attack.credential_access
- attack.t1003.0013. Wykrywanie w oparciu o anomalie
Wykrycia oparte na anomaliach ustanawiają: podstawa normalności tj zgłaszać istotne odchylenia. Na przykład, jeśli użytkownik zazwyczaj loguje się z z siedzibą we Włoszech w godzinach pracy, logowanie z Chin byłoby możliwe o 3 rano anomalia. Dzięki takiemu podejściu można wykryć zupełnie nieznane (zero-day) zagrożenia, ale ma tendencję do generowania większej liczby fałszywych alarmów, szczególnie w środowiskach dynamicznych.
4. Polowanie na zagrożenia
Polowanie na zagrożenia to proces proaktywne i oparte na hipotezach w którym analitycy aktywnie szukają zagrożeń, które mogły umknąć automatycznemu wykryciu. W przeciwieństwie do automatycznego wykrywania, polowanie na zagrożenia ma charakter eksploracyjny i często generuje nowe wykrycia, które są następnie kodowane i automatyzowane.
| Typ wykrywania | Precyzja | Ochrona typu zero-day | Fałszywie pozytywne | Konserwacja | Przykład |
|---|---|---|---|---|---|
| Oparte na podpisach | Bardzo wysoki | Nic | Bardzo niski | Wysoka (aktualizacja IOC) | Pliki haszujące, złośliwe adresy IP |
| Behawioralne | Wysoki | Dobry | Umiarkowane | Przeciętny | Dostęp LSASS, ruch boczny |
| Oparte na anomaliach | Zmienny | Doskonały | Wysoki | Wysoka (strojenie podstawowe) | Nieprawidłowe logowanie, nietypowy ruch |
| Polowanie na zagrożenia | Bardzo wysoki | Doskonały | Minimalna (ręczna) | Wysoki (wymaga analityków) | Analiza eksploracyjna, hipotezy |
Metryki jakości dla wykryć
Wykrywanie nie jest przydatne, jeśli tak nie jest wymierny. Metryki jakości pozwalają ocenić skuteczność reguł detekcji, pokierują procesem dostrojenie i uzasadnienie inwestycji w programie Detection Engineering.
Podstawowe wskaźniki operacyjne
| Metryczny | Opis | Cel | Jak ulepszyć |
|---|---|---|---|
| MTTD (Średni czas do wykrycia) | Średni czas od momentu szkodliwej aktywności do wygenerowania alertu | < 4 godziny (najlepszy zespół: < 30 min) | Lepszy zasięg logów, wykrywanie w czasie rzeczywistym |
| MTTR (Średni czas odpowiedzi) | Średni czas od wykrycia do zabezpieczenia/rozwiązania | < 4 godziny | Automatyzacja SOAR, zdefiniowane podręczniki |
| Prawdziwie dodatni wskaźnik (TPR) | Procent alertów odpowiadających realnym zagrożeniom | > 80% dla stanu krytycznego, > 60% dla stanu wysokiego | Ciągłe strojenie, zaawansowane filtrowanie |
| Fałszywie dodatni współczynnik (FPR) | Procent alertów wygenerowanych w związku z legalnymi działaniami | < 25% dla stanu krytycznego | Biała lista, wzbogacony kontekst, korelacja |
| Fałszywie ujemna stawka (FNR) | Procent niewykrytych realnych zagrożeń | <1% | Fioletowy zespół, polowanie na zagrożenia |
| Zasięg ATT&CK | Procent technik MITRE ATT&CK objętych co najmniej jednym wykryciem | > 70% odpowiednich technik | Regularna analiza luk, ustalanie priorytetów |
Obliczanie wyniku wykrywalności
Praktyczne podejście do oceny ogólnej jakości programu wykrywania i Wynik dojrzałości wykrywania, który łączy kilka wskaźników w jeden wynik znormalizowany. Oto przykładowe obliczenia w Pythonie:
from dataclasses import dataclass
from typing import List
@dataclass(frozen=True)
class DetectionMetrics:
"""Immutable snapshot of detection performance metrics."""
rule_id: str
true_positives: int
false_positives: int
false_negatives: int
total_alerts: int
avg_detection_time_minutes: float # MTTD
avg_response_time_minutes: float # MTTR
@property
def precision(self) -> float:
"""TP / (TP + FP) - How many alerts are real threats."""
denominator = self.true_positives + self.false_positives
return self.true_positives / denominator if denominator > 0 else 0.0
@property
def recall(self) -> float:
"""TP / (TP + FN) - How many real threats are caught."""
denominator = self.true_positives + self.false_negatives
return self.true_positives / denominator if denominator > 0 else 0.0
@property
def f1_score(self) -> float:
"""Harmonic mean of precision and recall."""
p, r = self.precision, self.recall
return 2 * (p * r) / (p + r) if (p + r) > 0 else 0.0
def calculate_maturity_score(metrics_list: List[DetectionMetrics]) -> dict:
"""Calculate overall detection program maturity score.
Returns an immutable dict with aggregated metrics.
"""
if not metrics_list:
return {"score": 0, "grade": "F", "details": {}}
avg_precision = sum(m.precision for m in metrics_list) / len(metrics_list)
avg_recall = sum(m.recall for m in metrics_list) / len(metrics_list)
avg_f1 = sum(m.f1_score for m in metrics_list) / len(metrics_list)
avg_mttd = sum(m.avg_detection_time_minutes for m in metrics_list) / len(metrics_list)
avg_mttr = sum(m.avg_response_time_minutes for m in metrics_list) / len(metrics_list)
# Weighted maturity score (0-100)
precision_score = avg_precision * 25 # 25% weight
recall_score = avg_recall * 25 # 25% weight
f1_component = avg_f1 * 20 # 20% weight
mttd_score = max(0, (240 - avg_mttd) / 240) * 15 # 15% weight (240min = 4h target)
mttr_score = max(0, (240 - avg_mttr) / 240) * 15 # 15% weight
total_score = (precision_score + recall_score + f1_component
+ mttd_score + mttr_score) * 100
grade_thresholds = [
(90, "A"), (80, "B"), (70, "C"), (60, "D")
]
grade = next(
(g for threshold, g in grade_thresholds if total_score >= threshold),
"F"
)
return {
"score": round(total_score, 1),
"grade": grade,
"details": {
"avg_precision": round(avg_precision, 3),
"avg_recall": round(avg_recall, 3),
"avg_f1": round(avg_f1, 3),
"avg_mttd_minutes": round(avg_mttd, 1),
"avg_mttr_minutes": round(avg_mttr, 1),
"total_rules_evaluated": len(metrics_list),
},
}
# Esempio di utilizzo
sample_metrics = [
DetectionMetrics("SIGMA-001", 45, 5, 2, 50, 15.0, 35.0),
DetectionMetrics("SIGMA-002", 120, 30, 8, 150, 8.5, 22.0),
DetectionMetrics("SIGMA-003", 200, 15, 5, 215, 3.2, 12.0),
]
result = calculate_maturity_score(sample_metrics)
print(f"Detection Maturity Score: {result['score']} ({result['grade']})")
print(f"Details: {result['details']}")Uwaga: wskaźniki próżności
Unikaj mierzenia sukcesu programu wykrywania za pomocą narzędzia całkowita liczba zasad lub liczba wygenerowanych alertów. To są metryki próżne wskaźniki, które mogą maskować poważne problemy. Organizacja zrzeszająca 50 wykrywanie o wysokiej wierności i znacznie bezpieczniejsze niż wykrywanie z 5000 generowanych reguł tysiące fałszywych alarmów, powodując zmęczenie czujności wśród analityków.
Ekosystem SIEM/SOAR
Il SIEM (Informacje o bezpieczeństwie i zarządzanie wydarzeniami) i serce infrastruktury Inżynierii Detekcyjnej. Oraz platforma, która zbiera, normalizuje, koreluje i analizuje logi ze wszystkich źródeł w organizacji. The SZYBOWAĆ (Orkiestracja bezpieczeństwa, automatyzacja i reagowanie) uzupełnia SIEM automatyzacja reakcji na alerty za pomocą predefiniowanych scenariuszy.
Przegląd głównych platform SIEM
| Platforma | Typ | Język zapytań | Mocne strony | Idealny przypadek użycia |
|---|---|---|---|---|
| Firma Splunk | Lokalnie / w chmurze | SPL | Dojrzałość, ekosystem aplikacji, elastyczność | Złożone przedsiębiorstwa, dojrzałe SOC |
| Elastyczny SIEM | Otwarte źródło/chmura | KQL / EQL / ES|QL | Open source, skalowalność, koszt | Niskobudżetowe zespoły natywne w chmurze |
| Strażnik Microsoftu | Chmura (Lazur) | KQL | Integracja z platformą Azure/M365, wbudowana sztuczna inteligencja | Organizacje skupione na Microsoft |
| Google SecOps (Kronika) | Chmura (GCP) | YARA-L | Nieograniczone przechowywanie, prędkość | Duże ilości danych, GCP |
| Skala logiczna CrowdStrike Falcon | Chmura | Zapytanie w skali logu | Szybkie spożycie, kompresja | Organizacje CrowdStrike |
| Logika sumo | Chmura | Zapytanie logiczne sumo | Natywny SaaS, łatwość obsługi | Najpierw chmura, z dużym obciążeniem SaaS |
Podstawowe źródła danych
Jakość wykrycia zależy bezpośrednio od jakości i kompletności danych dostępne. Oto podstawowe źródła danych skutecznego programu wykrywania:
- Telemetria punktów końcowych - Dzienniki procesów, zdarzenia w systemie plików, zmiany w rejestrze, połączenia sieciowe. Źródła: EDR (CrowdStrike, SentinelOne, Microsoft Defender), Sysmon
- Telemetria sieciowa - NetFlow, zapytania DNS, metadane HTTP/TLS, PCAP selektywny. Źródła: zapora ogniowa, IDS/IPS, proxy, narzędzie do rozpoznawania nazw DNS
- Tożsamość i dostęp - Zdarzenia uwierzytelniające, eskalacja uprawnień, zmiany członkostwa w grupie. Źródła: Active Directory, Entra ID, Okta, CyberArk
- Dzienniki audytu chmury - Wywołania API, zmiany konfiguracji, tworzenie zasobów. Źródła: AWS CloudTrail, dziennik aktywności platformy Azure, dzienniki audytu GCP
- Dzienniki aplikacji - Logi dostępu do serwera WWW, błędy aplikacji, zdarzenia WAF. Źródła: Nginx, Apache, CloudFront, aplikacje niestandardowe
- Bezpieczeństwo poczty e-mail - Próby phishingu, złośliwe załączniki, wykrywanie BEC. Źródła: Microsoft Defender dla O365, Proofpoint, Mimecast
Normalizacja danych: niewidzialny fundament
Bez normalizacja danychwykrycia są delikatne i nieprzenośne.
Każdy SIEM i każde źródło używa różnych formatów dla tych samych koncepcji: „błąd logowania”
może to wyglądać EventID 4625 w systemie Windows, sshd: Failed password
w Linuksie lub {"eventType": "user.session.start", "outcome": "FAILURE"}
w Okcie. Przyjmij schemat normalizacji, taki jak ECS (elastyczny wspólny schemat),
OCSF (otwarte ramy schematu cyberbezpieczeństwa) lub pozwala na to model danych Sigmy
aby zapisać wykrywanie tylko raz i zastosować je na dowolnym źródle.
Wykrywanie jako kod: nowoczesny paradygmat
Wykrywanie jako kod (DaC) oraz podejście, które stosuje praktyki rozwojowe oprogramowanie do zarządzania regułami detekcji. Zamiast tworzyć i modyfikować reguły za pośrednictwem interfejsu graficznego SIEM wykrycia są zapisywane w formie kodu i podlegają wersjonowaniu w repozytoriach Git, poddawany przeglądowi kodu poprzez pull requesty, automatycznie testowany i dostarczane za pośrednictwem rurociągów CI/CD.
Zalety wykrywania jako kodu
W porównaniu z podejściem tradycyjnym
- Wersjonowanie - Każda zmiana jest śledzona w Git, z możliwością wycofania
- Przegląd kodu - Wykrycia podlegają wzajemnej ocenie przed wdrożeniem
- Testy automatyczne - Automatyczna walidacja z danymi pozytywnymi i negatywnymi
- Powtarzalność - Z repozytorium można odtworzyć cały status wykrycia
Korzyści operacyjne
- Prędkość - Wykrycia trafiają do produkcji w ciągu kilku minut, a nie dni
- Konsystencja - Jednolicie stosowane standardy jakości
- Ścieżka audytu - Pełna identyfikowalność pod kątem zgodności
- Współpraca - Wiele zespołów może współtworzyć to samo repozytorium
Struktura repozytorium wykrywania jako kodu
detections/
rules/
credential_access/
lsass_memory_access.yml
brute_force_login.yml
kerberoasting.yml
execution/
powershell_encoded_command.yml
suspicious_wmi_execution.yml
lateral_movement/
psexec_usage.yml
rdp_from_unusual_source.yml
persistence/
scheduled_task_creation.yml
registry_run_key.yml
tests/
credential_access/
lsass_memory_access_test.json
brute_force_login_test.json
execution/
powershell_encoded_command_test.json
config/
sigma_config.yml
siem_mappings.yml
exclusions.yml
pipelines/
ci.yml
cd.yml
docs/
CONTRIBUTING.md
STYLE_GUIDE.md
REVIEW_CHECKLIST.md
README.mdPotok CI/CD do wykrywania
Potok wykrywania CI/CD automatyzuje cały proces od zatwierdzenia do produkcji. Oto przykładowa konfiguracja akcji GitHub:
name: Detection CI/CD Pipeline
on:
pull_request:
paths: ['rules/**', 'tests/**']
push:
branches: [main]
paths: ['rules/**']
jobs:
validate:
name: Validate Sigma Rules
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install sigma-cli
run: pip install sigma-cli pySigma-backend-splunk pySigma-backend-elasticsearch
- name: Lint Sigma Rules
run: |
sigma check rules/ --validation-config config/sigma_config.yml
echo "All rules pass validation"
- name: Verify ATT&CK Mapping
run: |
python scripts/verify_attack_tags.py rules/
echo "All rules have valid ATT&CK mappings"
test:
name: Test Detection Logic
needs: validate
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run True Positive Tests
run: |
python scripts/run_tests.py \
--rules-dir rules/ \
--tests-dir tests/ \
--test-type true_positive
- name: Run False Positive Tests
run: |
python scripts/run_tests.py \
--rules-dir rules/ \
--tests-dir tests/ \
--test-type false_positive
- name: Generate Coverage Report
run: python scripts/coverage_report.py --output reports/coverage.json
deploy:
name: Deploy to SIEM
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- name: Convert Sigma to Splunk SPL
run: |
sigma convert \
--target splunk \
--pipeline splunk_windows \
rules/ \
--output converted/splunk/
- name: Deploy to Splunk via API
env:
SPLUNK_TOKEN: ${{ secrets.SPLUNK_API_TOKEN }}
SPLUNK_URL: ${{ secrets.SPLUNK_URL }}
run: |
python scripts/deploy_splunk.py \
--rules-dir converted/splunk/ \
--splunk-url "$SPLUNK_URL" \
--token "$SPLUNK_TOKEN"
- name: Update ATT&CK Coverage Map
run: python scripts/update_attack_coverage.pyPełny proces wykrywania jako kodu
- Inżynier ds. wykrywania tworzy nową regułę Sigma w gałęzi Git
- Otwiera żądanie ściągnięcia z regułą i powiązanymi testami
- Potok CI przeprowadza walidację syntaktyczną, testowanie TP/FP oraz weryfikację mapowania ATT&CK
- Recenzent zatwierdza PR po sprawdzeniu logiki, dokumentacji i zakresu
- Łączenie z głównym aktywuje potok CD, który konwertuje regułę i dystrybuuje ją do SIEM
- Pulpity monitorujące śledzą skuteczność wykrywania w środowisku produkcyjnym
Pisanie skutecznych wykryć: zasady i wzorce
Różnica między wykrywaniem przeciętnym a doskonałym polega na głębokości wykrywania zrozumienie techniki ataku, w jakości filtrowania fałszywie pozytywnego i kompletności dokumentacji. Oto podstawowe zasady.
Zasada 1: Zacznij od techniki, a nie narzędzia
Nie pisz wykrycia dla "Mimikatz" - napisz wykrycie dla technika di zrzucanie poświadczeń poprzez dostęp do pamięci LSASS (T1003.001). To podejście obejmuje to automatycznie wszystkie narzędzia, które implementują tę samą technikę, w tym także te przyszłość jeszcze nieznana.
Zasada 2: Wykrywanie warstw (piramida wykrywania)
Zaimplementuj wykrywanie wielopoziomowe dla tej samej techniki. Wykrywanie oparte na haszu (trywialnie możliwe do uniknięcia) może nadal schwytać niewyrafinowanych napastników, podczas gdy a Detekcja behawioralna wychwytuje te bardziej zaawansowane. To warstwowe podejście i znany jako Wykrywanie w głębi.
Zasada 3: Zawsze dokumentuj kontekst
Każde wykrycie musi obejmować: motywacja (dlaczego to wykrycie istnieje), Mapowanie ATT&CK (jaką technikę obejmuje), tj fałszywe znane pozytywy (które legalne działania mogą wywołać regułę) oraz podręcznik odpowiedzi (co analityk musi zrobić po uruchomieniu wykrywania).
Kompletny przykład: wykrywanie za pomocą analizy logów w języku Python
"""
Brute Force Detection Module
MITRE ATT&CK: T1110.001 - Brute Force: Password Guessing
Detects multiple failed login attempts followed by a success.
"""
from dataclasses import dataclass, field
from datetime import datetime, timedelta
from collections import defaultdict
from typing import Optional
@dataclass(frozen=True)
class LoginEvent:
"""Immutable representation of a login event."""
timestamp: datetime
username: str
source_ip: str
success: bool
service: str # 'ssh', 'rdp', 'web', 'vpn'
@dataclass(frozen=True)
class BruteForceAlert:
"""Immutable alert generated by the detector."""
username: str
source_ip: str
failed_count: int
time_window_minutes: int
first_attempt: datetime
last_attempt: datetime
successful_login: bool
severity: str # 'medium', 'high', 'critical'
mitre_technique: str = "T1110.001"
@dataclass(frozen=True)
class DetectionConfig:
"""Immutable configuration for brute force detection."""
failed_threshold: int = 5
time_window_minutes: int = 10
lockout_threshold: int = 20
whitelist_ips: tuple = ()
monitored_services: tuple = ('ssh', 'rdp', 'web', 'vpn')
class BruteForceDetector:
"""Stateless brute force detection engine.
Analyzes login events and produces alerts when
brute force patterns are detected.
"""
def __init__(self, config: Optional[DetectionConfig] = None):
self._config = config or DetectionConfig()
def analyze(self, events: list[LoginEvent]) -> list[BruteForceAlert]:
"""Analyze a batch of login events for brute force patterns.
Returns a new list of alerts (no mutation of input).
"""
# Group events by (source_ip, username)
grouped = defaultdict(list)
for event in events:
if (event.service in self._config.monitored_services
and event.source_ip not in self._config.whitelist_ips):
key = (event.source_ip, event.username)
grouped[key].append(event)
alerts = []
for (source_ip, username), user_events in grouped.items():
sorted_events = sorted(user_events, key=lambda e: e.timestamp)
alert = self._check_brute_force(source_ip, username, sorted_events)
if alert is not None:
alerts.append(alert)
return alerts
def _check_brute_force(
self, source_ip: str, username: str, events: list[LoginEvent]
) -> Optional[BruteForceAlert]:
"""Check if events match a brute force pattern."""
window = timedelta(minutes=self._config.time_window_minutes)
failed_events = [e for e in events if not e.success]
if len(failed_events) < self._config.failed_threshold:
return None
# Check if failures cluster within the time window
for i, start_event in enumerate(failed_events):
window_end = start_event.timestamp + window
window_failures = [
e for e in failed_events[i:]
if e.timestamp <= window_end
]
if len(window_failures) >= self._config.failed_threshold:
# Check for subsequent successful login
success_after = any(
e.success and e.timestamp >= start_event.timestamp
for e in events
)
severity = self._calculate_severity(
len(window_failures), success_after
)
return BruteForceAlert(
username=username,
source_ip=source_ip,
failed_count=len(window_failures),
time_window_minutes=self._config.time_window_minutes,
first_attempt=window_failures[0].timestamp,
last_attempt=window_failures[-1].timestamp,
successful_login=success_after,
severity=severity,
)
return None
def _calculate_severity(self, failed_count: int, success: bool) -> str:
"""Determine alert severity based on pattern characteristics."""
if success and failed_count >= self._config.lockout_threshold:
return "critical" # Many failures + success = likely compromised
if success:
return "high" # Fewer failures + success = suspicious
if failed_count >= self._config.lockout_threshold:
return "high" # Many failures = active attack
return "medium" # Moderate failures = possible attackMITRE ATT&CK: ramy odniesienia
Ramy AT&CK UKOŚNIENIA (Taktyka kontradyktoryjna, techniki i wspólne Wiedza) i uniwersalne odniesienie do mapowania i klasyfikowania technik przeciwników. W przypadku inżynierii wykrywania ATT&CK zapewnia wspólny język opisu Co szukamy i matrycy do pomiaru zasięg z naszych wykrywanie.
Jak korzystać z ATT&CK w inżynierii wykrywania
- Priorytetyzacja - Nie wszystkie techniki ATT&CK są sobie równe istotne dla Twojej organizacji. Zidentyfikuj techniki najczęściej używane przez przeciwników w swoim sektorze (wywiad o zagrożeniach) i skoncentruj na nich zasoby.
- Analiza luk - Mapuj istniejące wykrycia na techniki ATT&CK aby zobaczyć odsłonięte obszary. Skorzystaj z Nawigator ATT&CK dla twórz mapy cieplne pokazujące aktualny zasięg.
-
Tagowanie - Każda Sigma i reguła detekcji muszą zawierać znaczniki ATT&CK
odpowiedni (np.
attack.t1003.001). Dzięki temu można agregować wskaźniki techniki i taktyki. - Pomiar - Śledź procent technik objętych każdą taktyką (Dostęp początkowy, Wykonanie, Trwałość itp.) i zdefiniuj realistyczne cele zasięgu.
| Taktyka | Przykładowe techniki | Kluczowe źródła danych | Wykrywanie trudności |
|---|---|---|---|
| Wstępny dostęp | T1566 Phishing, T1190 Exploit aplikacji publicznej | E-mail, WAF, proxy | Przeciętny |
| Wykonanie | Wiersz poleceń T1059, wykonanie użytkownika T1204 | Sysmon, EDR, logi procesów | Niski-Średni |
| Trwałość | Zaplanowane zadanie T1053, Autostart T1547 | Rejestr, system plików, EDR | Przeciętny |
| Eskalacja uprawnień | Eksploatacja T1068, ważne konta T1078 | EDR, logi AD, audyt chmury | Wysoki |
| Unikanie obrony | Usunięcie wskaźnika T1070, zaciemnienie T1027 | EDR, Sysmon, AMSI | Bardzo wysoki |
| Dostęp do danych uwierzytelniających | Zrzucanie danych uwierzytelniających systemu operacyjnego T1003, brutalna siła T1110 | Dzienniki EDR, AD, dzienniki uwierzytelniania | Przeciętny |
| Ruch boczny | Usługi zdalne T1021, boczne przenoszenie narzędzi T1570 | Sieć, dzienniki AD, EDR | Wysoki |
| Eksfiltracja | T1048 Eksfiltracja przez protokół Alt, usługa internetowa T1567 | DLP, proxy, DNS, NetFlow | Bardzo wysoki |
Struktura zespołu i role
Skuteczny program inżynierii wykrywania wymaga połączenia umiejętności które rzadko występują u jednej osoby. Struktura zespołu różni się w zależności od wielkości organizacji, ale kluczowe role są dobrze określone.
Kluczowe role
- Inżynier ds. wykrywania - Centralna rola. Pisze, testuje i utrzymuje zasady wykrywania. Wymaga umiejętności w zakresie analizy zagrożeń, języków zapytań SIEM i pisania skryptów (Python) i znajomość logów platformy docelowej. Według badania SANS Survey 2025: 60% organizacji ma co najmniej jednego dedykowanego inżyniera ds. wykrywania.
- Analityk analizy zagrożeń - Zapewnia kontekst zagrożeń: jakie Grupy APT są aktywne, jakich technik używają, jakich wskaźników szukać. To ich karmi hipoteza wykrywania z inteligencją, którą można zastosować.
- Inżynier danych / Architekt logów - Zajmuje się jakością i dostępnością danych: wdrażanie nowych źródeł logów, normalizacja, analizowanie i zarządzanie infrastruktury zbiórki.
- Analityk SOC - Użytkownik końcowy wykrywania. Dostarcza informacji zwrotnej ma fundamentalne znaczenie dla jakości ostrzeżeń: zbyt wiele fałszywych alarmów? Alert nie podlega działaniu? Brakuje informacji kontekstowych?
- Zespół Czerwony / Zespół Fioletowy - Symuluj techniki przeciwników, aby je sprawdzić wykrycia. Informacje zwrotne od zespołu czerwonych są najskuteczniejszym mechanizmem doskonalenia zasięg i wierność zasadom.
Organizacja dla małych zespołów
Nie każdą organizację stać na wynajęcie dedykowanego zespołu inżynierów ds. wykrywania. W przypadku mniejszych zespołów ds. bezpieczeństwa (3–5 osób) zalecane podejście jest następujące:
- Przypisz 20-30% czasu analityków SOC w Detection Engineering
- Przyjąć Zasady społeczności Sigma jako linia bazowa (repozytorium SigmaHQ)
- Wdrażaj a ustrukturyzowany proces informacji zwrotnej z segregacji alarmowej
- Używać Wykrywanie jako kod nawet przy prostych potokach (Git + skrypt wdrożeniowy)
- Skup się na 10-15 najbardziej odpowiednich technik ATT&CK dla Twojego sektora
Prawdziwy przypadek: od wypadku do rurociągu detekcyjnego
Aby skonkretyzować omawiane koncepcje, przyjrzyjmy się realistycznemu przykładowi całą ścieżkę od wykrycia luki do wykrycia w produkcji.
Scenariusz: kompromis za pomocą polecenia zakodowanego w programie PowerShell
Podczas fioletowego ćwiczenia drużyny Czerwonej udaje się wykonać złośliwy ładunek
używając programu PowerShell z poleceniem zakodowanym w formacie Base64 (-EncodedCommand).
Istniejące wykrywacze nie wykrywają ataku, ponieważ jedynie przeszukiwały
określone ciągi znanych poleceń programu PowerShell, a nie ogólny wzorzec kodowania.
Krok 1: Hipoteza i analiza
Inżynier detekcji formułuje hipotezę: „Każde użycie programu PowerShell
-EncodedCommand w środowisku korporacyjnym należy uznać za podejrzane, ponieważ
Legalne oprogramowanie rzadko musi kodować swoje polecenia.” Analiza
logów z ostatnich 30 dni potwierdza: z 50 000 uruchomień PowerShella tylko 12 korzysta
-EncodedCommand, a wszystkie można przypisać znanemu skryptowi automatyzacji IT.
Krok 2: Reguła Sigmy
title: Suspicious PowerShell Encoded Command Execution
id: f4a3b2c1-d5e6-7890-abcd-ef0123456789
status: test
description: |
Detects execution of PowerShell with encoded commands (-enc,
-EncodedCommand). Legitimate use is rare in enterprise environments.
Attackers commonly use this to obfuscate malicious payloads.
author: Federico Calo
date: 2025/12/01
modified: 2025/12/15
references:
- https://attack.mitre.org/techniques/T1059/001/
- https://attack.mitre.org/techniques/T1027/010/
logsource:
category: process_creation
product: windows
detection:
selection_powershell:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
selection_encoded:
CommandLine|contains:
- '-enc '
- '-EncodedCommand'
- '-encodedcommand'
- '-ec '
filter_known_automation:
ParentImage|endswith: '\sccm_agent.exe'
User|contains: 'SVC_AUTOMATION'
condition: selection_powershell and selection_encoded and not filter_known_automation
falsepositives:
- SCCM automation scripts (filtered)
- Custom IT automation using encoded commands (add to filter)
level: high
tags:
- attack.execution
- attack.t1059.001
- attack.defense_evasion
- attack.t1027.010Krok 3: Testowanie, wdrażanie i wyniki
Reguła jest testowana z 5 prawdziwie pozytywnymi scenariuszami (wariantami zakodowanego polecenia) i 20 fałszywie negatywne scenariusze (legalne wykonania programu PowerShell). Po wdrożeniu za pośrednictwem potoku CI/CD, w ciągu pierwszych 30 dni wykrycie generuje 8 alertów: 6 prawdziwie pozytywnych (podejrzane skrypty do analizy), 1 fałszywy alarm (nowy skrypt automatyzacji do dodania do filtra) i 1 krytyczny, prawdziwie pozytywny, prowadzący do wykrycia nieautoryzowanego dostępu.
Wymierne wyniki
- Precyzja: 87,5% (7 TP z 8 wszystkich alertów)
- MTTD: skrócono z „nie wykryto” do 4,2 minuty (średni czas generowania alertu)
- Zasięg ATT&CK: +2 techniki (T1059.001, T1027.010) dodane do mapy
- Prawdziwy wpływ: 1 aktywne uszkodzenie wykryte i usunięte w ciągu 45 minut
Wnioski i dalsze kroki
Inżynieria wykrywania reprezentuje zasadniczą zmianę paradygmatu w bezpieczeństwie operacyjny. Nie chodzi tylko o pisanie lepszych reguł w SIEM, ale o budowanie a kompletny proces inżynieryjny co obejmuje cały cykl życia detekcji: od hipotezy zagrożenia do walidacji w produkcji.
Kluczowe punkty do zapamiętania:
- Jakość przewyższa ilość - 50 wykryć o wysokiej wierności jest nieskończonych bardziej przydatne niż 5000 reguł generujących szum ostrzegawczy.
- Traktuj wykrycia jako kod - Wersjonowanie, przegląd kodu, testy automatyczne a rurociągi CI/CD nie są opcjonalne, lecz mają fundamentalne znaczenie.
- Zmierz wszystko - MTTD, MTTR, precyzja, wycofanie, zasięg ATT&CK. Bez wskaźników ciągła poprawa jest niemożliwa.
- Zacznij od techniki - Mapuj wykrycia do MITRE ATT&CK i skoncentruj się zasoby dotyczące technik najbardziej odpowiednich dla Twojej organizacji.
- Zainwestuj w jakość danych - Bez niego idealne i bezużyteczne wykrywanie dane, na których można operować. Normalizacja i wdrażanie źródeł logów to: niewidzialny fundament całego programu.
W następnym artykule
W kolejnym artykule z serii zagłębimy się w nie Zasady Sigmy: standardowy format zapisywania przenośnych wykryć. Zobaczymy pełną składnię, zaawansowane modyfikatory, backendy konwersji dla głównych SIEM, a my zbudujemy kompletny zestaw zasad dla najważniejszych technik ATT&CK.