Field Mapping and Log Sources

Sigma’s power comes from its abstraction layer. The same rule works across SIEM platforms because Sigma backends translate logsource definitions and field names automatically.

How Backends Resolve Fields

When you compile a Sigma rule, the backend does three things:

1. Resolves the logsource — maps category: process_creation, product: windows to the correct index/dataset (e.g. Sysmon Event 1, win-ev in QRadar)
2. Maps field names — translates Sigma field names (e.g. Image) to platform-specific names (e.g. process.executable in Elastic)
3. Translates modifiers — converts contains to *value* or LIKE '%value%' depending on the backend

Common Logsource Categories

logsource:
  category: process_creation      # Process started
  category: network_connection    # Outbound TCP/UDP
  category: dns_query             # DNS lookup
  category: file_event            # File created/modified
  category: registry_event        # Registry key changed
  category: image_load            # DLL/module loaded

Writing Platform-Agnostic Rules

Best practices for maximum portability:

1. Use standard field names — stick to the canonical Sigma field names from the spec
2. Avoid platform-specific syntax — no SPL eval, no KQL project
3. Test with multiple backends — compile your rule against at least 2-3 targets before marking status: stable
4. Document false positives — the falsepositives field is mandatory for stable rules