01 - Detekční inženýrství: od disciplíny přes skript k potrubí
V neustále se vyvíjejícím prostředí kybernetických hrozeb schopnost zjistit škodlivá aktivita před tím, než způsobí značné škody, představuje skutečný rozdíl mezi odolná a zranitelná organizace. Po desetiletí byla detekce hrozeb svěřeno ad hoc písemným pravidlům, antivirovým podpisům a individuálním intuicím analytiků SOC. dnes, tento řemeslný přístup již není udržitelný: objem kulatiny, složitost Nativní cloudové infrastruktury a sofistikovanost útočníků vyžadují přístup inženýrské a systematické.
Takhle se to zrodilo Detekční inženýrství: disciplína, která uplatňuje zásady softwarového inženýrství k procesu vytváření, testování, nasazování a údržby softwaru detekční pravidla. Už to není o psaní izolovaných dotazů v SIEM, je to o budování automatizovaná potrubí, verze detekcí jako kód, test je s daty simulovat a měřit je objektivními metrikami.
Co se dozvíte v tomto článku
- Co je detekční inženýrství a proč se stalo autonomní disciplínou
- Vývoj od ad hoc skriptů k CI/CD kanálům pro detekci
- Kompletní životní cyklus detekce: hypotéza, vývoj, test, nasazení, ladění
- Hlavní typy detekce: na základě signatur, behaviorální, anomálie
- Metriky kvality: True Positive Rate, False Positive Rate, MTTD, MTTR
- Ekosystém SIEM/SOAR a klíčové zdroje dat
- Koncept Detection-as-Code a CI/CD kanálů pro bezpečnostní pravidla
- Praktické příklady s pravidly Sigma, skripty Python a konfiguracemi YAML
Co je detekční inženýrství
La Detekční inženýrství a systematický proces navrhování, vývoje, testování a údržba logiky, která identifikuje škodlivou aktivitu v rámci telemetrie organizace. Tato telemetrie zahrnuje protokoly z koncových bodů, cloudové infrastruktury, poskytovatelé identit, webové aplikace, síťové systémy a mnoho dalšího.
Na rozdíl od tradičního přístupu, kdy analytik SOC zapsal dotaz do SIEM v reakci na konkrétní incident přijímá Detection Engineering a pracovní postup strukturovaný připomínající moderní vývoj softwaru: verze kódu, kontrola kódu, automatizované testování, nepřetržité nasazení a sledování výkonu ve výrobě.
„Detekční inženýrství je pro SOC tím, čím je softwarové inženýrství pro kódování: transformuje ad-hoc, reaktivní činnost v systematickou, měřitelnou a neustále se zlepšující disciplínu."
- SANS Institute, 2025 Detection Engineering Survey
Tři pilíře detekční techniky
Disciplína je založena na třech vzájemně propojených pilířích, které definují její vyspělost:
- Threat Intelligence - Pochopte, kdo jsou protivníci, jaké techniky používají (MITRE ATT&CK), a která aktiva organizace jsou ohrožena. Bez pochopení hloubky hrozeb budou detekce obecné a nepříliš účinné.
- datové inženýrství - Zajistěte, aby byly shromážděny a normalizovány potřebné protokoly a dostupné pro analýzu. Dokonalá a zbytečná detekce, pokud data, na kterých pracuje, nejsou přítomny nebo jsou nekvalitní.
- Softwarové inženýrství - Aplikujte osvědčené postupy vývoje softwaru: kontrola verzí, testování, CI/CD, dokumentace, metriky. Detekce musí být ošetřeny jako výrobní kód.
Evoluce: od ad hoc skriptů po inženýrskou disciplínu
Cestu, která vedla k modernímu detekčnímu inženýrství, lze rozdělit do čtyř odlišné fáze, z nichž každá je charakterizována rostoucí úrovní zralosti a automatizace.
Fáze 1: Éra podpisů (1990–2005)
Rané formy detekce byly založeny na statické podpisy: známé vzory malware, hash škodlivých souborů, specifické řetězce v síťových nákladech. Každý antivirus a IDS (Intrusion Detection System) udržoval databázi signatur, která byla pravidelně aktualizována. Tento přístup fungoval poměrně dobře se známými hrozbami, ale byl zcela slepý k novým variantám nebo přizpůsobeným útokům.
Fáze 2: The Age of SIEM Scripts (2005–2015)
S rozšířením býv SIEM (bezpečnostní informace a správa událostí), analytici začali psát vlastní dotazy a korelace. Každý analytik měl vlastní přístup, vlastní scénáře, vlastní konvence pojmenování. Pravidla byla vytvořena přímo ve webovém rozhraní SIEM, bez verzování, bez testování, bez dokumentace standardizované. Když analytik opustil organizaci, jeho nebo její odhalení se často stalo pro nástupce nepochopitelné.
Fáze 3: The Birth of Detection Engineering (2015–2022)
Mezi lety 2015 a 2022 si bezpečnostní komunita začíná uvědomovat potřebu a strukturovanější přístup. Rodí se standardní formáty jako např Sigma (2017) pro pravidla detekce, rámec MITRE ATT&CK se stane referencí univerzální pro mapování technik protivníků a první specializované detekční týmy Inženýrství se objevuje ve vyspělejších organizacích.
Fáze 4: Detection-as-Code a CI/CD Pipeline (2022-současnost)
Dnes nejpokročilejší organizace zacházejí s detekcemi přesně jako se softwarovým kódem. Pravidla jsou napsána v deklarativních formátech (Sigma, YAML), verzována v repozitářích Git, automaticky testováno se simulovanými daty, nasazeno prostřednictvím kanálu CI/CD a monitorováno s vyhrazenými přístrojovými deskami. Podle SANS 2025 Detection Engineering Survey, 60 % organizací má vyhrazené týmy detekčního inženýrství, přičemž 70 % podniků s více než 5 000 zaměstnanci, které již vytvořily strukturované týmy.
| Fáze | Období | Přístup | Nástroje | Limity |
|---|---|---|---|---|
| Statické podpisy | 1990-2005 | Shoda vzorů na známých podpisech | Antivirus, IDS (Snort) | Neviditelné zero-days, vysoká latence |
| SIEM skripty | 2005-2015 | Ad hoc dotazy v SIEM | Splunk, ArcSight, QRadar | Neverzované, netestované, znalosti umlčené |
| Detekční inženýrství | 2015–2022 | Strukturovaný pracovní postup se standardy | Sigma, ATT&CK, ELK | Stále mnoho manuálních procesů |
| Detekce jako kód | 2022-současnost | CI/CD potrubí, všechny verze | Git, CI/CD, Sigma, SOAR | Vyžaduje organizační vyspělost |
Životní cyklus detekce
Každá detekce sleduje dobře definovaný životní cyklus, který zaručuje kvalitu, účinnost a udržovatelnost v průběhu času. Cyklus se skládá ze šesti základních fází, z nichž každá má výstupy a konkrétní kritéria kvality.
1. Hypotéza (Hypothesis)
Všechno to začíná jedním hypotéza ohrožení. Analytik nebo detekční inženýr identifikuje konkrétní techniku útoku (např. „Útočník by mohl využít PowerShell ke stažení a spuštění škodlivého datového zatížení") a formulovat hypotézu o tom, jak tato činnost by se projevila v dostupných protokolech. Mezi zdroje hypotéz patří:
- Threat Intelligence - Zpráva o aktivních kampaních, pozorovaných TTP
- MITRE ATT&CK - Techniky mapované na konkrétní taktiku
- Posmrtná nehoda - Poučení z předchozích incidentů
- Zjištění červeného týmu - Výsledky penetračních testů a fialového teamingu
- Analýza mezer - Techniky ATT&CK bez pokrytí detekcí
2. Vývoj (vývoj)
S definovanou hypotézou detekční technik napíše detekční pravidlo. Toto zahrnuje volbu formátu (Sigma, nativní dotaz SIEM, skript Python), definici nezbytných zdrojových protokolů, logiky výběru a filtrování a dokumentace metadata (autor, závažnost, mapování ATT&CK, známá falešná pozitiva).
3. Testování a ověřování (testování)
Před nasazením musí být detekce ověřena oproti skutečným a simulovaným datům. Testování zahrnuje: skutečně pozitivní testování (detekuje pravidlo simulovaný útok?), falešně pozitivní testování (generuje pravidlo upozornění na legitimní aktivity?), e testování výkonu (pravidlo je dostatečně účinné na objemy výrobní protokol?).
4. Nasazení
K nasazení dochází prostřednictvím automatizovaných kanálů, které převádějí pravidlo do formátu nativní pro cílový SIEM, nasadit jej do produkčního prostředí a ověřit jeho správnost operace. Ve vyspělých prostředích je tento proces plně automatizován prostřednictvím CI/CD.
5. Monitorování a metriky
Jakmile jsou ve výrobě, detekce je neustále monitorována. Klíčové metriky zahrnují objem generovaných výstrah, poměr pravdivě/falešně pozitivních, průměrnou dobu detekce (MTTD) a dopad na zatížení analytika SOC.
6. Ladění a údržba
Na základě dat shromážděných ve výrobě se detekce průběžně zpřesňuje. The ladění může zahrnovat přidání výjimek pro opakující se falešně pozitivní výsledky, rozšíření logiky k pokrytí variací techniky nebo zavržení pravidla, pokud ne více relevantní.
Nejlepší postup: Purple Teaming
Il fialové týmování výrazně zrychluje zpětnovazební smyčku životní cyklus detekce. Kombinace ofenzivních schopností červeného týmu s obrannými Modrého týmu je možné simulovat techniky skutečného útoku a ověřovat detekce v v reálném čase, což zkracuje dobu mezi hypotézou a ověřenou detekcí z týdnů na hodiny.
Typy detekce: od MOV po chování
Detekce lze klasifikovat na základě použité detekční logiky. Každý typ má specifické výhody a omezení a vyspělý detekční program je kombinuje vše stratifikovaným způsobem.
1. Detekce na základě podpisu
Vyhledávání detekce na základě podpisu přesné vzory v datech: hash souboru známé, specifické řetězce v příkazech, IP adresách nebo známých škodlivých doménách (IOC - Indicators kompromisu). Je to nejjednodušší a nejrychlejší typ s velmi nízkou mírou falešně pozitivních, ale zcela neúčinné proti novým nebo variantním hrozbám.
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. Detekce chování
Hledají se detekce chování akční sekvence nebo vzor chování, které naznačuje podezřelou aktivitu, bez ohledu na konkrétní MOV. Například místo hledání konkrétního hash Mimikatz, detekce chování mohl vyhledat jakýkoli proces přistupující k paměti LSASS, aby extrahoval přihlašovací údaje. Tento přístup je mnohem odolnější vůči únikům, protože se útočníci mohou změnit své vlastní nástroje, ale stěží mohou změnit základní techniku.
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. Detekce na základě anomálií
Detekce na základě anomálií stanoví a základní linii normality e hlásit výrazné odchylky. Pokud se například uživatel obvykle přihlašuje z a se sídlem v Itálii během pracovní doby, přihlášení z Číny ve 3 hodiny ráno by bylo anomálie. Tento přístup dokáže detekovat zcela neznámé (zero-day) hrozby, ale má tendenci generovat více falešných poplachů, zejména v dynamických prostředích.
4. Lov hrozeb
Hledání hrozeb je proces proaktivní a založený na hypotézách ve kterém se analytici aktivně hledají hrozby, které mohly uniknout automatické detekci. Na rozdíl od automatické detekce je vyhledávání hrozeb průzkumné a často vytváří nové detekce, které jsou pak kodifikovány a automatizovány.
| Typ detekce | Přesnost | Pokrytí Zero-Day | Falešná pozitiva | Údržba | Příklad |
|---|---|---|---|---|---|
| Na základě podpisu | Velmi vysoká | Žádný | Velmi nízké | Vysoká (aktualizace IOC) | Hash soubory, škodlivé IP adresy |
| Behaviorální | Vysoký | Dobrý | Moderuje | Průměrný | Přístup LSASS, boční pohyb |
| Na základě anomálie | Variabilní | Vynikající | Vysoký | Vysoká (základní ladění) | Neobvyklé přihlášení, neobvyklý provoz |
| Lov hrozeb | Velmi vysoká | Vynikající | Minimum (manuální) | Vysoká (vyžaduje analytiky) | Explorační analýza, hypotézy |
Metriky kvality pro detekce
Detekce není užitečná, pokud není měřitelný. Metriky kvality umožňují vyhodnotit účinnost pravidel detekce, vést proces vyladění a zdůvodnění investic do programu Detection Engineering.
Základní provozní metriky
| Metrický | Popis | Cíl | Jak se zlepšit |
|---|---|---|---|
| MTTD (střední doba detekce) | Průměrná doba od okamžiku škodlivé aktivity do vygenerování výstrahy | < 4 hodiny (nejlepší tým: < 30 minut) | Lepší pokrytí protokolů, detekce v reálném čase |
| MTTR (střední doba na odpověď) | Průměrná doba od zjištění k omezení/rozlišení | < 4 hodiny | Automatizace SOAR, definované playbooky |
| Skutečně pozitivní sazba (TPR) | Procento výstrah, které odpovídají skutečným hrozbám | > 80 % pro kritické, > 60 % pro vysoké | Průběžné ladění, pokročilé filtrování |
| Falešně pozitivní sazba (FPR) | Procento upozornění generovaných pro legitimní aktivity | < 25 % pro kritické | Whitelist, obohacený kontext, korelace |
| Falešně negativní sazba (FNR) | Procento skutečných nezjištěných hrozeb | < 1 % | Fialový tým, lov hrozeb |
| Pokrytí ATT&CK | Procento technik MITER ATT&CK pokrytých alespoň jednou detekcí | > 70 % příslušných technik | Pravidelná analýza mezer, stanovení priorit |
Výpočet skóre detekce
Praktický přístup k hodnocení celkové kvality detekčního programu a Skóre zralosti detekce, který kombinuje několik metrik do jednoho skóre normalizované. Zde je příklad výpočtu v Pythonu:
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']}")Pozor: metriky marnosti
Vyhněte se měření úspěšnosti vašeho detekčního programu pomocí celkový počet pravidel nebo počet vygenerovaných upozornění. Toto jsou metriky metriky marnosti, které mohou maskovat vážné problémy. Organizace s 50 vysoce věrná detekce a mnohem bezpečnější než ten s 5 000 generujícími pravidly tisíce falešně pozitivních výsledků, což mezi analytiky způsobuje únavu.
Ekosystém SIEM/SOAR
Il SIEM (Bezpečnostní informace a správa událostí) a srdce infrastruktury detekčního inženýrství. A platforma, která shromažďuje, normalizuje, koreluje a analyzuje protokoly ze všech zdrojů v organizaci. The VZDÁT SE (Security Orchestration, Automation and Response) doplňuje SIEM automatizace reakcí na výstrahy prostřednictvím předdefinovaných příruček.
Přehled hlavních platforem SIEM
| Platforma | Typ | Jazyk dotazu | Silné stránky | Ideální případ použití |
|---|---|---|---|---|
| Splunk Enterprise | On-Prem / Cloud | SPL | Vyspělost, ekosystém aplikací, flexibilita | Komplexní podniky, vyspělé SOC |
| Elastické SIEM | Open Source / Cloud | KQL / EQL / ES|QL | Open source, škálovatelnost, cena | Nízkorozpočtové, cloudové nativní týmy |
| Microsoft Sentinel | Cloud (Azure) | KQL | Integrace Azure/M365, vestavěná AI | Organizace zaměřené na Microsoft |
| Google SecOps (kronika) | Cloud (GCP) | YARA-L | Neomezená retence, rychlost | Velké objemy dat, GCP |
| CrowdStrike Falcon LogScale | Mrak | Dotaz LogScale | Rychlé požití, komprese | Organizace CrowdStrike |
| Logika sumo | Mrak | Sumo logický dotaz | Nativní SaaS, snadné použití | Cloud-first, SaaS-heavy |
Základní zdroje dat
Kvalita detekcí přímo závisí na kvalitě a úplnosti dat k dispozici. Zde jsou základní zdroje dat pro efektivní detekční program:
- Telemetrie koncového bodu - Protokoly procesů, události souborového systému, změny registru, síťová připojení. Zdroje: EDR (CrowdStrike, SentinelOne, Microsoft Defender), Sysmon
- Síťová telemetrie - NetFlow, DNS dotazy, HTTP/TLS metadata, PCAP selektivní. Zdroje: firewall, IDS/IPS, proxy, DNS resolver
- Identita a přístup - Autentizační události, eskalace oprávnění, změny členství ve skupině. Zdroje: Active Directory, Entra ID, Okta, CyberArk
- Protokoly cloudového auditu - Volání API, změny konfigurace, vytváření zdrojů. Zdroje: AWS CloudTrail, Azure Activity Log, GCP Audit Logs
- Protokoly aplikací - Protokoly přístupu k webovému serveru, chyby aplikací, události WAF. Zdroje: Nginx, Apache, CloudFront, vlastní aplikace
- Zabezpečení e-mailu - Pokusy o phishing, škodlivé přílohy, detekce BEC. Zdroje: Microsoft Defender pro O365, Proofpoint, Mimecast
Normalizace dat: Invisible Foundation
Bez normalizace dat, detekce jsou křehké a nejsou přenosné.
Každý SIEM a každý zdroj používá různé formáty pro stejné pojmy: "selhání přihlášení"
může to vypadat EventID 4625 na Windows, sshd: Failed password
v Linuxu, popř {"eventType": "user.session.start", "outcome": "FAILURE"}
v Okta. Přijmout normalizační schéma jako např ECS (Elastic Common Schema),
OCSF (Open Cybersecurity Schema Framework) nebo umožňuje datový model Sigmy
zapsat detekci pouze jednou a aplikovat ji na jakýkoli zdroj.
Detekce jako kód: moderní paradigma
Detekce jako kód (DaC) a přístup, který uplatňuje postupy rozvoje software pro správu pravidel detekce. Místo vytváření a úprav pravidel přes grafické rozhraní SIEM jsou detekce zapsány jako kód, verze v repozitářích Git, podrobené kontrole kódu prostřednictvím požadavků na stažení, automaticky testovány a dodávány prostřednictvím potrubí CI/CD.
Výhody detekce jako kódu
Ve srovnání s tradičním přístupem
- Verzování - Každá změna je sledována v Gitu s možností vrácení zpět
- Kontrola kódu - Detekce procházejí před nasazením peer review
- Automatizované testy - Automatická validace s pozitivními a negativními daty
- Reprodukovatelnost - Celý stav detekcí lze rekonstruovat z úložiště
Provozní výhody
- Rychlost - Detekce jdou do výroby během minut, ne dnů
- Konzistence - Jednotně uplatňované standardy kvality
- Audit Trail - Úplná sledovatelnost dodržování předpisů
- Spolupráce - Do stejného úložiště může přispívat více týmů
Struktura úložiště detekce jako kódu
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.mdCI/CD potrubí pro detekce
Detekční potrubí CI/CD automatizuje celý proces od zadání až po výrobu. Zde je příklad konfigurace pro akce 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.pyKompletní tok detekce jako kódu
- Detekční technik vytvoří nové pravidlo Sigma ve větvi Git
- Otevře požadavek Pull s pravidlem a souvisejícími testy
- CI pipeline provádí syntaktické ověření, testování TP/FP a ověření mapování ATT&CK
- Po kontrole logiky, dokumentace a pokrytí PR schválí peer reviewer
- Sloučení do hlavního aktivuje kanál CD, který převede pravidlo a distribuuje je do SIEM
- Monitorovací řídicí panely sledují výkon detekce ve výrobě
Zápis efektivních detekcí: Principy a vzory
Rozdíl mezi průměrnou a vynikající detekcí spočívá v hloubce detekce pochopení techniky útoku v kvalitě falešně pozitivního filtrování a v úplnosti dokumentace. Zde jsou základní principy.
Princip 1: Začněte s technikou, ne s nástrojem
Nezapisujte detekci pro "Mimikatz" - napište detekci pro technika di dumping pověření prostřednictvím přístupu do paměti LSASS (T1003.001). Tento přístup to pokrývá automaticky všechny nástroje, které implementují stejnou techniku, včetně těch budoucnost zatím neznámá.
Princip 2: Detekce vrstev (detekční pyramida)
Implementujte víceúrovňovou detekci pro stejnou techniku. Detekce založená na hash (triviálně se dá vyhnout) může stále zajmout nenáročné útočníky, zatímco a Detekce chování zachytí ty pokročilejší. Tento vrstvený přístup a známý jako Detekce do hloubky.
Zásada 3: Vždy dokumentujte kontext
Každá detekce musí obsahovat: motivace (proč tato detekce existuje), ATT&CK mapování (kterou techniku pokrývá), tzn falešný známá pozitiva (které legitimní aktivity mohou spustit pravidlo) a Příručka odpovědí (co musí analytik udělat, když je detekce spuštěna).
Úplný příklad: Detekce pomocí Log Analysis 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: Referenční rámec
Rámec MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) a univerzální odkaz pro mapování a klasifikaci technik oponentů. Pro Detection Engineering poskytuje ATT&CK společný jazyk pro popis Co hledáme a matici k měření krytí našich detekce.
Jak používat ATT&CK pro detekční inženýrství
- Stanovení priorit - Ne všechny techniky ATT&CK jsou si rovné relevantní pro vaši organizaci. Identifikujte techniky, které soupeři nejčastěji používají ve vašem sektoru (informace o hrozbách) a soustřeďte na ně zdroje.
- Analýza mezer - Mapujte existující detekce na techniky ATT&CK pro zobrazení nepokrytých oblastí. Použijte Navigátor ATT&CK pro vytvářet tepelné mapy zobrazující aktuální pokrytí.
-
Označování - Každé pravidlo Sigma a detekce musí obsahovat značky ATT&CK
odpovídající (např.
attack.t1003.001). To vám umožní agregovat metriky pro techniku a taktiku. - Měření - Sledujte procento technik pokrytých pro každou taktiku (Initial Access, Execution, Persistence, atd.) a definovat realistické cíle pokrytí.
| Taktika | Příklady technik | Klíčové zdroje dat | Detekce obtížnosti |
|---|---|---|---|
| Počáteční přístup | T1566 Phishing, T1190 Exploit Public App | E-mail, WAF, proxy | Průměrný |
| Provedení | Příkazový řádek T1059, spouštění uživatelem T1204 | Sysmon, EDR, protokoly procesů | Nízká až střední |
| Perzistence | T1053 Naplánovaná úloha, T1547 Autostart spouštění | Registr, souborový systém, EDR | Průměrný |
| Eskalace privilegií | T1068 Exploitation, T1078 Platné účty | EDR, protokoly AD, cloudový audit | Vysoký |
| Obranný únik | T1070 Odstranění indikátoru, T1027 zmatek | EDR, Sysmon, AMSI | Velmi vysoká |
| Přístup k pověření | T1003 OS Credential Dumping, T1110 Brute Force | EDR, protokoly AD, protokoly ověřování | Průměrný |
| Laterální pohyb | T1021 Remote Services, T1570 Lateral Transfer Tool | Síť, protokoly AD, EDR | Vysoký |
| Exfiltrace | T1048 Exfiltration Over Alt Protocol, T1567 Web Service | DLP, proxy, DNS, NetFlow | Velmi vysoká |
Struktura týmu a role
Efektivní program detekčního inženýrství vyžaduje kombinaci dovedností které se zřídka vyskytují u jediného člověka. Struktura týmu se liší velikosti organizace, ale klíčové role jsou dobře definovány.
Klíčové role
- Detekční inženýr - Ústřední role. Píše, testuje a udržuje pravidla detekce. Vyžaduje dovednosti v inteligenci hrozeb, dotazovacích jazycích SIEM, skriptování (Python) a znalost protokolů cílové platformy. Podle průzkumu SANS 2025 60 % organizací má alespoň jednoho specializovaného detekčního inženýra.
- Threat Intelligence Analyst - Poskytuje kontext o hrozbách: které z nich Skupiny APT jsou aktivní, jaké techniky používají, jaké indikátory hledat. Živí je to detekční hypotéza s akční inteligencí.
- Data Engineer / Log Architect - Zabývá se kvalitou a dostupností dat: začleňování nových zdrojů protokolů, normalizace, analýza a správa sběrné infrastruktury.
- Analytik SOC - Koncový uživatel detekcí. Poskytuje zpětnou vazbu zásadní pro kvalitu výstrah: příliš mnoho falešných poplachů? Upozornění nelze provést? Chybí vám kontextové informace?
- Červený tým / Fialový tým - Simulujte techniky oponentů k ověření detekce. Zpětná vazba červeného týmu je nejúčinnějším mechanismem pro zlepšování pokrytí a věrnost pravidlům.
Organizace pro malé týmy
Ne každá organizace si může dovolit specializovaný tým detekční techniky. Pro menší bezpečnostní týmy (3–5 osob) je doporučený postup:
- Přiřadit 20-30% času analytiků SOC ve společnosti Detection Engineering
- Přijmout Pravidla komunity Sigma jako základní (úložiště SigmaHQ)
- Implementujte a strukturovaný proces zpětné vazby z poplachového třídění
- Použití Detekce jako kód i s jednoduchými kanály (Git + skript nasazení)
- Soustřeďte se na 10-15 nejdůležitějších technik ATT&CK pro váš sektor
Skutečný případ: od nehody k detekčnímu potrubí
Aby byly diskutované pojmy konkrétní, ukažme si pro ilustraci realistický příklad celou cestu od objevení mezery k detekci ve výrobě.
Scénář: Kompromis pomocí příkazu PowerShell Encoded
Během fialového týmového cvičení se červenému týmu podaří provést škodlivý náklad
pomocí PowerShellu s příkazem kódovaným Base64 (-EncodedCommand).
Útok není detekován existujícími detekcemi, protože pouze hledaly
konkrétní řetězce známých příkazů PowerShellu, nikoli obecný vzor kódování.
Krok 1: Hypotéza a analýza
Detekční inženýr formuluje hypotézu: „Jakékoli použití PowerShellu
-EncodedCommand v podnikovém prostředí by měl být považován za podezřelý, protože
Legitimní software jen zřídka potřebuje kódovat své příkazy." Analýza
z protokolů za posledních 30 dní potvrzuje: z 50 000 spuštění PowerShellu pouze 12 používá
-EncodedCommanda všechny lze připsat známému automatizačnímu skriptu IT.
Krok 2: Pravidlo Sigma
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: Test, nasazení a výsledky
Pravidlo je testováno s 5 skutečně pozitivními scénáři (varianty zakódovaného příkazu) a 20 falešně negativní scénáře (legitimní spuštění PowerShellu). Po nasazení přes potrubí CI/CD, v prvních 30 dnech detekce vygeneruje 8 výstrah: 6 pravdivě pozitivních (podezřelé skripty analyzovat), 1 falešně pozitivní (nový automatizační skript pro přidání do filtru) a 1 kritický skutečný pozitivní výsledek vedoucí k odhalení neoprávněného přístupu.
Měřitelné výsledky
- Přesnost: 87,5 % (7 TP z 8 celkových upozornění)
- MTTD: sníženo z „nezjištěno“ na 4,2 minuty (průměrná doba generování výstrahy)
- Pokrytí ATT&CK: +2 techniky (T1059.001, T1027.010) přidány do mapy
- Skutečný dopad: 1 aktivní poškození objeveno a odstraněno během 45 minut
Závěry a další kroky
Detekční inženýrství představuje zásadní posun paradigmatu v zabezpečení provozní. Není to jen o psaní lepších pravidel v SIEM, je to o budování a kompletní inženýrský proces který pokrývá celý životní cyklus detekcí: od hypotézy ohrožení po validaci ve výrobě.
Klíčové body k zapamatování:
- Kvalita převyšuje kvantitu - 50 vysoce věrných detekcí je nekonečně užitečnější než 5 000 pravidel, která generují výstražný šum.
- Považujte detekce za kód - Verze, kontrola kódu, automatizované testy a CI/CD potrubí nejsou volitelné, jsou základní.
- Vše změřte - MTTD, MTTR, přesnost, odvolání, pokrytí ATT&CK. Bez metriky, neustálé zlepšování je nemožné.
- Začněte od techniky - Mapujte detekce na MITER ATT&CK a soustřeďte se zdroje o technikách, které jsou pro vaši organizaci nejrelevantnější.
- Investujte do kvality dat - Bez ní perfektní a zbytečná detekce data, se kterými se má pracovat. Normalizace a onboarding zdrojů protokolu jsou neviditelný základ celého programu.
V dalším článku
V dalším článku seriálu se jim budeme věnovat hlouběji Pravidla Sigmy: standardní formát pro zápis přenosných detekcí. Uvidíme úplnou syntaxi, pokročilé modifikátory, konverzní backendy pro hlavní SIEM a my vytvoříme kompletní soubor pravidel pro nejkritičtější techniky ATT&CK.