DETECTION ENGINEERING
OVERVIEW#
Detection engineering turns adversary behavior into reliable, tuned alerts. This sheet covers the Sigma rule format, the sigma CLI / sigconverter translation to SIEM queries (QRadar AQL, Sentinel/Defender KQL, Splunk SPL, Elastic), ATT&CK mapping, and tuning workflow.
DETECTION LIFECYCLE#
# 1. Hypothesis - pick an ATT&CK technique / threat behavior # 2. Data check - confirm log source + fields exist (DaC) # 3. Author - write vendor-neutral Sigma rule # 4. Convert - translate to target SIEM query # 5. Test - validate with Atomic Red Team / purple team # 6. Tune - reduce FP, add allowlists, set severity # 7. Deploy + doc - version control, ATT&CK tag, runbook
SIGMA RULE STRUCTURE#
# title: short, action-oriented
# id: UUID (stable across edits)
# status: experimental | test | stable
# logsource: { product, category, service }
# detection: { selection: {...}, condition: selection }
# falsepositives, level (low|medium|high|critical), tags (attack.tXXXX)
MINIMAL SIGMA EXAMPLE#
# title: Certutil Download # logsource: # category: process_creation # product: windows # detection: # selection: # Image|endswith: '\certutil.exe' # CommandLine|contains: # - 'urlcache' # - '-f http' # condition: selection # level: high # tags: [attack.command_and_control, attack.t1105]
SIGMA CLI - CONVERT#
sigma convert -t <backend> rule.yml # Convert one rule
sigma convert -t splunk rule.yml # -> SPL
sigma convert -t elasticsearch rule.yml # -> Lucene/ES|QL
sigma convert -t kusto rule.yml # -> KQL (Sentinel/Defender)
sigma convert -t qradar rule.yml # -> AQL (via plugin)
sigma convert -t <backend> -p <pipeline> rule.yml
# Apply field mapping
sigma plugin list # Available backends
sigma plugin install <backend> # Install a backend
FIELD MAPPING PIPELINES#
# Sigma uses neutral field names; pipelines map to your schema: sigma convert -t kusto -p sentinel-windows rule.yml sigma convert -t kusto -p microsoft_xdr rule.yml # Defender XDR tables sigma convert -t splunk -p splunk_windows rule.yml # Mismatched fields = silent no-match; always apply the right pipeline
ATT&CK MAPPING#
# Tag every rule with technique IDs for coverage tracking: # tags: [attack.t1059.001, attack.execution] # Build a coverage matrix (ATT&CK Navigator layer) to find gaps # Prioritize by threat intel relevant to the sector (finance TTPs)
TUNING WORKFLOW#
# - Baseline in audit/log-only mode before alerting # - Add filter/allowlist blocks for known-good (admin tools, scanners) # - Use condition: selection and not filter # - Track FP rate; a rule > ~5% FP needs rework or context enrichment # - Enrich with asset criticality, identity risk, geo
TEST & VALIDATE#
# Atomic Red Team - execute a technique, confirm the alert fires: Invoke-AtomicTest T1059.001 # Run a technique test Invoke-AtomicTest T1105 -ShowDetailsBrief # Preview # Purple-team: attacker runs TTP, defender confirms detection + timing
EXAMPLES#
# Convert a Sigma rule to Defender XDR KQL with correct field mapping sigma convert -t kusto -p microsoft_xdr certutil_download.yml # Bulk-convert a ruleset to Splunk SPL sigma convert -t splunk -p splunk_windows ./rules/ > splunk_rules.txt # Validate the deployed detection actually triggers Invoke-AtomicTest T1105 -TestNumbers 1
NOTES#
- Sigma is the vendor-neutral source of truth; keep rules in git and generate SIEM-specific queries at deploy time - "Detection as Code" (DaC): PR review, CI conversion, versioning - Always confirm the LOG SOURCE exists before writing a rule - no process_creation logging (Sysmon/4688 w/ cmdline) = no detection - QRadar users: convert to AQL, then wrap in a rule with building blocks; verify field extraction (custom properties) first - Map detection coverage to NIS2 detection requirements + DORA ICT incident management for FS clients - Pair with DEFENDER-KQL.txt, SENTINEL-KQL.txt, and the SIGMA sheet
DETECTION ENGINEERING CHEATSHEET
================================
Source: https://cheatsheet.johlem.net
OVERVIEW
--------
Detection engineering turns adversary behavior into reliable, tuned
alerts. This sheet covers the Sigma rule format, the sigma CLI /
sigconverter translation to SIEM queries (QRadar AQL, Sentinel/Defender
KQL, Splunk SPL, Elastic), ATT&CK mapping, and tuning workflow.
DETECTION LIFECYCLE
-------------------
# 1. Hypothesis - pick an ATT&CK technique / threat behavior
# 2. Data check - confirm log source + fields exist (DaC)
# 3. Author - write vendor-neutral Sigma rule
# 4. Convert - translate to target SIEM query
# 5. Test - validate with Atomic Red Team / purple team
# 6. Tune - reduce FP, add allowlists, set severity
# 7. Deploy + doc - version control, ATT&CK tag, runbook
SIGMA RULE STRUCTURE
--------------------
# title: short, action-oriented
# id: UUID (stable across edits)
# status: experimental | test | stable
# logsource: { product, category, service }
# detection: { selection: {...}, condition: selection }
# falsepositives, level (low|medium|high|critical), tags (attack.tXXXX)
MINIMAL SIGMA EXAMPLE
---------------------
# title: Certutil Download
# logsource:
# category: process_creation
# product: windows
# detection:
# selection:
# Image|endswith: '\certutil.exe'
# CommandLine|contains:
# - 'urlcache'
# - '-f http'
# condition: selection
# level: high
# tags: [attack.command_and_control, attack.t1105]
SIGMA CLI - CONVERT
-------------------
sigma convert -t <backend> rule.yml # Convert one rule
sigma convert -t splunk rule.yml # -> SPL
sigma convert -t elasticsearch rule.yml # -> Lucene/ES|QL
sigma convert -t kusto rule.yml # -> KQL (Sentinel/Defender)
sigma convert -t qradar rule.yml # -> AQL (via plugin)
sigma convert -t <backend> -p <pipeline> rule.yml
# Apply field mapping
sigma plugin list # Available backends
sigma plugin install <backend> # Install a backend
FIELD MAPPING PIPELINES
-----------------------
# Sigma uses neutral field names; pipelines map to your schema:
sigma convert -t kusto -p sentinel-windows rule.yml
sigma convert -t kusto -p microsoft_xdr rule.yml # Defender XDR tables
sigma convert -t splunk -p splunk_windows rule.yml
# Mismatched fields = silent no-match; always apply the right pipeline
ATT&CK MAPPING
--------------
# Tag every rule with technique IDs for coverage tracking:
# tags: [attack.t1059.001, attack.execution]
# Build a coverage matrix (ATT&CK Navigator layer) to find gaps
# Prioritize by threat intel relevant to the sector (finance TTPs)
TUNING WORKFLOW
---------------
# - Baseline in audit/log-only mode before alerting
# - Add filter/allowlist blocks for known-good (admin tools, scanners)
# - Use condition: selection and not filter
# - Track FP rate; a rule > ~5% FP needs rework or context enrichment
# - Enrich with asset criticality, identity risk, geo
TEST & VALIDATE
---------------
# Atomic Red Team - execute a technique, confirm the alert fires:
Invoke-AtomicTest T1059.001 # Run a technique test
Invoke-AtomicTest T1105 -ShowDetailsBrief # Preview
# Purple-team: attacker runs TTP, defender confirms detection + timing
EXAMPLES
--------
# Convert a Sigma rule to Defender XDR KQL with correct field mapping
sigma convert -t kusto -p microsoft_xdr certutil_download.yml
# Bulk-convert a ruleset to Splunk SPL
sigma convert -t splunk -p splunk_windows ./rules/ > splunk_rules.txt
# Validate the deployed detection actually triggers
Invoke-AtomicTest T1105 -TestNumbers 1
NOTES
-----
- Sigma is the vendor-neutral source of truth; keep rules in git and
generate SIEM-specific queries at deploy time
- "Detection as Code" (DaC): PR review, CI conversion, versioning
- Always confirm the LOG SOURCE exists before writing a rule - no
process_creation logging (Sysmon/4688 w/ cmdline) = no detection
- QRadar users: convert to AQL, then wrap in a rule with building
blocks; verify field extraction (custom properties) first
- Map detection coverage to NIS2 detection requirements + DORA ICT
incident management for FS clients
- Pair with DEFENDER-KQL.txt, SENTINEL-KQL.txt, and the SIGMA sheet
Defensive reference on CyberRamen. Offensive / red-team sheets live on OffensiveRamen.com.