Field Mapping & Data-Source Dependencies

What is it?

A Sigma field name (e.g. CommandLine) must map to the actual field in your data (Sysmon's CommandLine, or a SIEM's normalized field). A rule also depends on the data being collected at all — no process-creation logging, no process rule.

Why it matters

A perfect rule matches nothing if the field name does not map or the data is not collected. Most 'the rule doesn't work' problems are mapping or missing telemetry, not the logic.

Where you see it

A field-mapping/config that says Sigma's `Image` = the SIEM's `process.executable`; a coverage gap where command-line auditing is off so CommandLine is empty.

What normal looks like

Rule fields mapped to real collected fields, and the required telemetry (process creation, command line) confirmed present before relying on the rule.

What suspicious looks like

A rule referencing CommandLine on a host where command-line auditing is disabled (it silently never matches), or a field name that does not exist in your schema.

How analysts investigate

Before trusting a rule, confirm its fields map to real fields and its required telemetry is collected; a rule that matches nothing is often a data gap, not a logic error.

Common beginner mistakes

Assuming a rule works without checking the field mapping and telemetry.
Blaming the logic when the real issue is missing command-line auditing.

The rule needs the data

  Sigma field   →  your data
    Image       →  process.executable   (mapping config)
    CommandLine  →  (EMPTY: cmdline auditing OFF)  ← rule can't match
  a rule matching nothing = mapping gap or missing telemetry, not logic

Sigma fields must map to real fields, and the required telemetry must be collected, or the rule matches nothing.

Quick check

Your CommandLine-based rule never fires, though the attack happened. Most likely cause?

A quick self-check — it doesn't affect your XP or progress.