Jak wykorzystać MITRE ATT&CK do tworzenia i mapowania reguł detekcji w SIEM

1. Wprowadzenie — od TTP do reguł detekcji

W pierwszej części tej serii omówiliśmy, czym są TTP (Tactics, Techniques and Procedures), jak budować profil zagrożeń i jak na jego podstawie definiować strategię odporności organizacji. Wiemy już, kto może nas zaatakować i jakimi metodami. Czas przełożyć tę wiedzę na konkretne działanie — czyli reguły detekcji w SIEM.

Sama wiedza o technikach przeciwnika jest solidnym fundamentem, ale pozostaje akademicka, jeśli nie zamieni się w działające mechanizmy wykrywania. MITRE ATT&CK Framework oferuje tu znacznie więcej niż katalog zagrożeń — każda technika zawiera wskazówki detekcyjne (Detection Strategies), które stanowią punkt wyjścia do budowy reguł: jakie dane zbierać, z jakich źródeł oraz jakie atrybuty analizować. Uzupełnieniem może być szereg innych narzędzi i standardów z czego zaproponuję dwa bardzo praktyczne: Cyber Analytics Repository (CAR) jako zbiór gotowych wzorców analitycznych oraz Sigma jako vendor-agnostic i uniwersalny format reguł.

Artykuł przeprowadzi Cię przez całą ścieżkę:

• MITRE ATT&CK Detection Strategy → Log Sources I mutable Elements,
• MITRE CAR → gotowe schematy analityczne,
• Sigma → implementacja reguły,
• SIEM → egzekucja, strojenie i monitorowanie pokrycia.

2. Od techniki ATT&CK do strategii detekcji

W wersji ATT&CK v18, wydanej 28 października 2025 roku tradycyjne sekcje Detections (Data Sources) zostały zastąpione przez Detection Strategies i Analytics. Wprowadzono dwupoziomowy model detekcji: Detection Strategies (oznaczane DETxxxx) — określają ogólne podejścia do wykrywania konkretnych technik stosowanych przez atakujących. Oraz pełnią rolę ram porządkujących specyficzne metody analizy opisane przez Analytics (ANxxxx) — konkretne implementacje detekcji oparte na telemetrii i zachowaniach. Technika w bazie ATT&CK posiada dedykowaną sekcję Detection, która odpowiada na trzy pytania: co zbierać, z jakiego źródła i na jakim poziomie szczegółowości.

2.1. Nowy model — trzy warstwy detekcji

Nowy model składa się z trzech powiązanych obiektów STIX:

Obiekt	Identyfikator	Rola w modelu
Detection Strategy	DETxxxx	Wysokopoziomowy opis zachowania przeciwnika, które należy wykryć. Powiązany relacją „detects” z konkretną techniką ATT&CK. Każda technika ma jeden obiekt DET.
Analytic	ANxxxx	Implementacja detekcji dla konkretnej platformy np. Windows, Linux, chmury. Zawiera logikę detekcji, progi i odwołania do Log Sources.
Data Component	DCxxxx	Typ telemetrii (np. Process Creation, API Call). Nadal obecny, ale teraz zakorzeniony bezpośrednio w obiekcie Analytic przez pole x_mitre_log_source_references, a nie jako samodzielna relacja z techniką.

Relacja między obiektami wygląda następująco: technika ATT&CK wskazuje na Detection Strategy → Detection Strategy odwołuje się do Analytic → Analytic zawiera Log Sources zbudowane na Data Components.

2.2. Detection Strategy — co to jest w praktyce

Detection Strategy (DET) to obiekt opisujący, jakie zachowanie przeciwnika ma być wykryte, nie zaś jak dokładnie napisać zapytanie. To warstwa strategiczna — odpowiada na pytanie „co szukamy”. Przykłady:

• DET0363 — Detection of Credential Dumping from LSASS Memory via Access and Dump Sequence – Technika: T1003.001 (LSASS Memory) | Taktyka: Credential Access
• DET0441 — Detection of Suspicious Scheduled Task Creation and Execution on Windows – Technika: T1053.005 (Scheduled Task) | Taktyka: Execution / Persistence
• DET0455 — Abuse of PowerShell for Arbitrary Execution – Technika: T1059.001 (PowerShell) | Taktyka: Execution

Techniki ATT&CK są mapowane do obiektów Detection Strategy, które pełnią rolę wysokopoziomowych kontenerów dla analytics.

2.3. Analytic — warstwa operacyjna

Analytic (AN) to warstwa, która zamienia strategię w działanie. Każdy obiekt AN jest platformo-specyficzny — jeden DET może mieć osobny AN dla Windows, osobny dla Linux i osobny dla AWS. Analytic zawiera:

• opis logiki detekcji behawioralnej (co i w jakim kontekściie jest podejrzane),
• odwołania do Log Sources z konkretną nazwą i kanałem (np. wineventlog:security, auditd:SYSCALL, sysmon:1),
• odwołania do Data Components przez pole x_mitre_log_source_references,
• opcjonalne progi i parametry strojenia.

Kluczowa zaleta: Log Sources mają teraz jednoznaczne nazwy w formacie „źródło:kanał”. Zamiast ogólnego „Sysmon” — konkretnie „sysmon:1” (process create). Zamiast „Windows Event Log” — „wineventlog:security” lub „wineventlog:system”.

2.4 Log Sources — skąd zbierać dane

Poniższa tabela przedstawia przykładowe mapowanie dla techniki T1003 (OS Credential Dumping) na różnych platformach:

Platforma	Data Component	Log Source	Przykładowe zdarzenia
Windows	process_creation	Windows Event Log / Sysmon	EID 4688 (process), Sysmon EID 1
Windows	os_api_execution	Sysmon (EID 10)	OpenProcess na lsass.exe
Linux	process_creation	auditd / syslog	execve() na ‘/proc/*/mem’, dostęp do /proc/<pid>/mem lub ptrace()
AWS	cloud_service	CloudTrail	GetSecretValue, AssumeRole z nieznanego IP, z nietypowej lokalizacji geograficznej lub poza baseline użytkownika
Azure AD	logon_session	Azure AD Sign-in Logs	Nieoczekiwane logowania, impossible travel

2.5. Przykład: T1003.001

Poniższa tabela ilustruje, jak nowy model działa dla T10003.001 — LSASS Memory:

Warstwa	Obiekt	Treść
Technika	T1003.001	LSASS Memory (Taktyka: Credential Access)
Detection Strategy	DET0363	Detection of Credential Dumping from LSASS Memory via Access and Dump Sequence — nieuprzywilejowany proces otwiera uchwyt z pełnym dostępem do lsass.exe, po czym następuje dump pamięci, zapis pliku lub modyfikacja rejestru
Analytic (Windows)	AN1030	Detekcja łańcucha behawioralnego: Process Access na lsass.exe (GrantedAccess=0x1F0FFF) + File Creation lub Registry Modification w krótkim oknie czasowym
Data Components	DC0035, DC0032, DC0039, DC0013, DC0063	Process Access, Process Creation, File Creation, User Account Metadata, Windows Registry Key Modification
Log Sources	WinEventLog:Sysmon,	EventCode=10 (DC0035), EventCode=1 (DC0032)

W poprzednim modelu ta sama technika miała listę Data Sources (Command: Windows Command Shell, Process: Process Creation itd.) i ogólny blok tekstu z opisem detekcji. Nowy model jest modularny, wersjonowany i bezpośrednio wskazuje konkretne kanały logów.

Wniosek praktyczny: Zanim zaczniesz pisać regułę, zweryfikuj w sekcji Detection danej techniki, które Log Sources są wymagane i czy Twój SIEM je odbiera oraz poprawnie parsuje. Reguła oparta na nieistniejącym źródle danych nigdy nie zadziała.

2.6. Mutable Elements — na co uważać przy budowie reguły

Jednym z kluczowych błędów jest opieranie detekcji na elementach łatwych do zmiany:

• hashe plików,
• adresy IP,
• domeny,
• nazwy plików.

Mutable Elements to atrybuty logu, które atakujący może stosunkowo łatwo zmodyfikować. Atakujący może je zmienić w kilka sekund. Z kolei trudne do zmiany są:

• zachowanie,
• sekwencja działań,
• interakcje między komponentami systemu.

Dlatego efektywne reguły SIEM powinny opierać się na zachowaniu, nie artefaktach.

Atrybut logu	Typ	Uwaga
Nazwa procesu (Image)	Mutable	Łatwa do zmiany; atakujący kopiuje nazwy procesów systemowych (np. svchost.exe)
CommandLine	Mutable / kontekstowe	Zaciemnianie (Base64, znaki specjalne); bardzo silne po normalizacji
ParentProcessId / ParentImage	Trudny do sfałszowania	Związek rodzic–dziecko w drzewie procesów; wartościowe dla detekcji
ProcessId	Mutable	PID rotuje; bez korelacji z innymi polami — niska wartość
FileHash (SHA256)	Trudny do podrobienia, ale łatwy do obejścia poprzez zmianę binarki.	. Najlepszy do detekcji znanych artefaktów; wymaga aktualnych IoC
IntegrityLevel	Trudny do sfałszowania, choć możliwe są techniki jego manipulacji (np. PPID spoofing, process injection)	Wskazuje na eskalację uprawnień; wartościowy dla reguł privilege escalation
ProcessPath (pełna ścieżka)	Częściowo mutable	Silny wskaźnik przy porównaniu z oczekiwaną lokalizacją (np. katalogi systemowe). Podatny na maskaradę poprzez uruchomienie binarki o tej samej nazwie z innej lokalizacji lub wykorzystanie technik takich jak process hollowing czy DLL sideloading.

Reguły oparte wyłącznie na nazwie procesu lub fragmencie CommandLine generują dużo fałszywych alarmów. Korelacja z ParentImage, IntegrityLevel lub ścieżką pliku znacząco podnosi precyzję.

3. MITRE Cyber Analytics Repository (CAR)

MITRE Cyber Analytics Repository (CAR) to repozytorium gotowych wzorców analitycznych powiązanych z konkretnymi technikami ATT&CK. Można traktować je jako operacyjny pomost między teorią (ATT&CK) a implementacją (Sigma, zapytania SIEM).

3.1. Struktura analityki CAR

Każda analityka w CAR zawiera:

• mapowanie na ATT&CK: Taktykę, Technikę i opcjonalnie Sub-technikę,
• opis behawioralny: co i dlaczego jest podejrzane,
• pseudokod analityczny: logika warunku detekcji niezależna od platformy,
• implementacje: przykładowe zapytania w wybranych językach, np. Splunk SPL, EQL, Logpoint; część analityk ma także wariant Sigma,
• wymagane Data Sources: lista pól i źródeł potrzebnych do działania analityki,
• poziom pewności (Coverage) i szacunkowe false positive risk.

4. Sigma — uniwersalny język reguł detekcji

Sigma jest dla reguł SIEM tym, czym Snort dla IDS lub YARA dla analizy złośliwego oprogramowania — vendor-agnostic, deklaratywnym formatem YAML, który pozwala opisać logikę detekcji i przetłumaczyć ją na dowolny dialekt zapytań: Splunk SPL, Elastic EQL, QRadar AQL, Microsoft Sentinel KQL, SIEM SVQL i wiele innych.

4.1. Anatomia reguły Sigma

Reguła Sigma składa się z kilku obowiązkowych i opcjonalnych sekcji:

Sekcja	Opis	Przykład
title	Krótka nazwa reguły	LSASS Memory Dump via ProcDump
status	Dojrzałość reguły	experimental / test / stable
logsource	Źródło logów: product, category, service	product: windows\ncategory: process_creation
detection	Logika detekcji: selection + condition	Patrz poniżej na sekcję Detection w przykładowej regule
tags	Mapowanie na ATT&CK i inne frameworki	attack.t1003.001, attack.credential_access
falsepositives	Znane false positives	Autoryzowane narzędzia diagnostyczne IT
level	Krytyczność alertu	low / medium / high / critical

4.2. Przykład kompletnej reguły Sigma dla T1003.001

Poniższa reguła wykrywa podejrzany dostęp do procesu lsass.exe (Process Access), który jest charakterystycznym etapem technik credential dumpingu mapowanych do T1003.001.

4.3. Ekosystem Sigma

Sigma to nie tylko format — to rozbudowany ekosystem narzędzi i zasobów:

Komponent	Opis	URL
SigmaHQ (GitHub)	Centralne repozytorium reguł społeczności (4000+ reguł)	github.com/SigmaHQ/sigma
sigma-cli / pySigma	Konwerter reguł do Splunk SPL, KQL, EQL, AQL i in.	github.com/SigmaHQ/sigma-cli, https://github.com/SigmaHQ/pySigma
MITRE ATT&CK Navigator	Wizualizacja pokrycia detekcji na macierzy ATT&CK	mitre-attack.github.io/attack-navigator

5. Praktyczne zastosowanie w SIEM

Poniższe kroki opisują konkretny proces — od importu reguł do operacyjnego strojenia i raportowania pokrycia ATT&CK.

5.1. Import i mapowanie reguł

SIEM obsługuje import reguł w formacie natywnym dla swojego silnika korelacyjnego. Aby skorzystać z reguł Sigma, należy je najpierw skompilować do odpowiedniego formatu:

1. Zmapuj odpowiednie identyfikatory technik zidentyfikowane w trakcje profilowania zagrożeń na wzorce analityk w repozytorium CAR.
2. Sprawdź pseudokody i reguły SIGMA przypisane do technik.
3. Pobierz aktualne reguły SIGMA (np. z repozytorium SigmaHQ na GitHub).
4. Przefiltruj reguły istotne dla Twojego profilu zagrożeń (tagi ATT&CK odpowiadające technikom zidentyfikowanym w profilu zagrożen).
5. Skompiluj reguły do formatu obsługiwanego przez SIĘ (np. używając narzędzia pySigma)
6. Zaimportuj skompilowane reguły do SIEM.
7. Przypisz tagi ATT&CK do każdej reguły w interfejsie SIEM — to podstawa późniejszego raportowania pokrycia.
8. Dostosuj zaimportowane reguły do specyfiki środowiska i kontekstu biznesowego.

5.2. Konfiguracja i weryfikacja źródeł danych

Przed aktywacją reguły należy zweryfikować, czy wymagane Log Sources są podłączone do SIEM i poprawnie parsowane. Poniżej przykładowa lista kontrolna:

Log Source	Wymagane zdarzenia	Status do weryfikacji
Windows Event Log	EID 4688 (proces), 4624/4625 (logowanie), 4663 (dostęp do pliku), 4698 (sched. task)	Wymaga audit policy: Process Creation = Success
Sysmon	EID 1 (proces), 3 (sieć), 7 (DLL), 8 (CreateRemoteThread), 10 (ProcessAccess)	Wymaga wdrożenia Sysmon z konfiguracją (np. SwiftOnSecurity)
PowerShell	EID 4103 (Module Logging), 4104 (Script Block Logging)	Wymaga włączenia ScriptBlockLogging w GPO
EDR / XDR	Telemetria procesów, sieci, plików	Zależne od produktu; weryfikacja parsera w SIEM
DNS / Proxy	Zapytania DNS, URL, kategorie	Niezbędne dla technik C2 i exfiltracji
CloudTrail / Azure AD	API calls, logowania, zmiany konfiguracji	Konieczne dla środowisk hybrydowych i chmurowych

5.3. Cykl utrzymania reguł

Reguły detekcji degradują się w czasie — atakujący adaptują techniki, środowisko się zmienia. Minimalny cykl utrzymania:

Częstotliwość	Działanie
Miesięcznie	Pula nowych reguł i ocena ich przydatności dla profilu zagrożeń
Miesięcznie	Przegląd reguł generujących > X alertów tygodniowo — weryfikacja jakości (false positive rate)
Kwartalnie	Aktualizacja profilu zagrożeń (nowe grupy APT, nowe techniki); mapowanie na lukę w pokryciu
Kwartalnie	Test reguł za pomocą symulacji (np. Atomic Red Team lub własne skrypty testowe); walidacja end-to-end
Rocznie	Pełny przegląd biblioteki reguł: deprecjacja przestarzałych, konsolidacja duplikatów

Narzędzie Atomic Red Team (github.com/redcanaryco/atomic-red-team) to zbiór drobnych testów symulacyjnych zmapowanych 1:1 na techniki ATT&CK. Uruchomienie testu dla T1003.001 przed wdrożeniem reguły pozwala zweryfikować, czy reguła faktycznie zadziała w Twoim środowisku.

6. Podsumowanie

Cała opisana ścieżka wygląda następująco: profil zagrożeń (TTP) → ATT&CK Detection Strategy → CAR jako wzorzec analityk→ Sigma jako uniwersalny format implementacji → SIEM jako egzekucja i monitoring.

Kluczowe wnioski:

• MITRE ATT&CK to nie tylko baza wiedzy, ale fundament inżynierii detekcji opartej na TTP.
  Pozwala przejść od ogólnego rozumienia zagrożeń do konkretnych, mierzalnych mechanizmów wykrywania
• Skuteczna detekcja zaczyna się od danych, nie od reguł

Bez właściwie zdefiniowanych, uruchomionych i poprawnie zbieranych źródeł telemetrycznych nawet najlepsza logika detekcji nie zadziała.

• Artefakty takie jak IP, hash czy nazwa pliku są łatwe do zmiany, natomiast zachowanie atakującego pozostaje w dużej mierze niezmienne.

Największą wartość mają detekcje łączące analizę behawioralną (Indicators of Attack – IoA) z analizą opartą na artefaktach (Indicators of Compromise – IOC).

• Pojedyncze zdarzenia mają niską wartość detekcyjną — kluczowa jest korelacja.

Dopiero powiązanie procesów, użytkowników, sesji i zdarzeń w czasie pozwala zbudować wiarygodny alert.

• CAR i Sigma znacząco usprawniają proces tworzenia i utrzymania reguł detekcji.

CAR dostarcza gotowe wzorce logiki analitycznej, a Sigma umożliwia ich przenoszenie i zastosowanie na różnych platformach SIEM.

• Detekcja to proces ciągły, a nie jednorazowe wdrożenie.

Reguły wymagają regularnego strojenia, walidacji i aktualizacji w odpowiedzi na zmieniające się techniki przeciwnika i środowiska organizacji.

• Pomiar pokrycia detekcji dla zidentyfikowanych zagrożeń jest kluczowy dla świadomego zarządzania bezpieczeństwem.

Pozwala identyfikować luki, priorytetyzować rozwój detekcji i podejmować decyzje oparte na danych.

Organizacje, które potrafią przełożyć TTP na detekcję, przestają jedynie reagować na incydenty — zaczynają rozpoznawać i wykrywać przeciwnika w trakcie działania.

Materiały źródłowe

• MITRE ATT&CK Framework: attack.mitre.org
• MITRE Cyber Analytics Repository: car.mitre.org
• SigmaHQ — reguły Sigma: github.com/SigmaHQ/sigma
• sigma-cli (konwerter): github.com/SigmaHQ/sigma-cli
• ATT&CK Navigator: mitre-attack.github.io/attack-navigator
• Atomic Red Team: github.com/redcanaryco/atomic-red-team
• Sysmon konfiguracja (SwiftOnSecurity):

---

Marcin Fronczak