Builtin Pipelines

RSigma embeds three ready-to-use processing pipelines in the binary so common Windows deployments work with no external YAML file. Reference them by name from any subcommand that accepts -p:

rsigma engine eval   -r rules/ -p ecs_windows -e @events.ndjson
rsigma engine daemon -r rules/ -p sysmon
rsigma backend convert rules/ -t fibratus -p fibratus_windows
rsigma backend convert rules/ -t postgres -p ecs_windows

Builtins are baked at compile time. Updating their content means upgrading rsigma; they are not file-watched, do not appear under --reload, and cannot be tweaked at runtime. Copy the YAML out to a local file (sources below) if you need to customize.

The builtin registry is the source of truth (ecs_windows, fibratus_windows, sysmon via builtin_names()). Extra YAML files may live under crates/rsigma-eval/pipelines/ (for example gcp_audit.yml) without being builtins; load those by path with -p path/to/file.yml.

ecs_windows

Maps generic Sigma / Sysmon field names to Elastic Common Schema (ECS) as produced by Winlogbeat and Elastic Agent. Derived from pySigma-backend-elasticsearch’s ecs_windows pipeline.

rsigma engine eval -r rules/ -p ecs_windows \
    -e '{"process.command_line": "whoami", "winlog.channel": "Microsoft-Windows-Sysmon/Operational"}'

Priority: 20. Source: pipelines/ecs_windows.yml.

What it maps

Each transformation is gated by rule_conditions: logsource.category so only the relevant logsource categories receive each rename.

Pair with the right input

ecs_windows assumes the agent has already flattened the Windows events into ECS shape. It does NOT flatten raw .evtx records (those are nested under Event.System.* and Event.EventData.*). For raw .evtx files, use dotted-path rules or write a custom flattening pipeline. See Input Formats: EVTX.

fibratus_windows

Maps Sigma Windows logsource categories and PascalCase fields onto Fibratus kernel-event names and the lowercase-dotted Fibratus vocabulary (ps.exe, ps.cmdline, file.path, net.dip, …). Use it when converting Windows rules to Fibratus YAML so the output matches upstream Fibratus rules-library style.

rsigma backend convert -t fibratus -p fibratus_windows rules/windows/process_creation/

Priority: 20. Source: pipelines/fibratus_windows.yml.

What it does

• field_name_mapping renames Sigma fields to Fibratus attributes per category (process_creation, network_connection, file_event, image_load, registry_*, dns_query, pipe_created, create_remote_thread, and related).
• add_condition injects evt.name discriminators (for example CreateProcess, Connect) so Fibratus can short-circuit on the event name before the rest of the body.
• Field notes follow Fibratus 3.0.0: on CreateProcess, ps.* describes the created (child) process and ps.parent.* the parent; cross-process targets use evt.arg[...].

Pair with backend convert -t fibratus and the Fibratus backend reference.

sysmon

Adds EventID routing conditions so logsource-scoped rules (e.g. category: process_creation) match the corresponding Sysmon event types when evaluating raw Sysmon JSON. Derived from pySigma-pipeline-sysmon.

rsigma engine eval -r rules/ -p sysmon \
    -e '{"EventID": 1, "Image": "cmd.exe", "CommandLine": "whoami"}'

Priority: 10. Source: pipelines/sysmon.yml.

What it adds

Each transformation is add_condition with a matching rule_conditions: logsource.category. The injected condition combines with the rule’s own selection via AND.

After the routing conditions, a final change_logsource rewrites every Windows rule to product: windows, service: sysmon so downstream backends can use the unified logsource.

That rewrite is also the routing decision itself, in a form a consumer can read: rather than re-deriving which channel a process_creation rule belongs to, read logsource.service off the transformed rule. Use Engine::rules() after loading, or transform_collection when you need the rule without loading it. A custom pipeline that routes by add_condition alone leaves the logsource untouched, so mirror this closing transformation if anything downstream keys off service.

When it does NOT help

sysmon assumes events already have a flat EventID field. It does not flatten the nested EVTX shape. For raw .evtx input, either:

• Reference fields by their dotted EVTX path (Event.System.EventID: 1) directly in the rule, or
• Write a pipeline that field_name_mapping-renames Event.System.EventID to EventID before sysmon runs (higher priority:).

Chaining builtins with file pipelines

Builtin and file pipelines compose by priority: (lower runs first). A typical Windows ECS deployment:

rsigma engine daemon -r rules/ \
    -p sysmon \
    -p ecs_windows \
    -p /etc/rsigma/pipelines/org-overrides.yml

sysmon (priority 10) adds the EventID conditions first; ecs_windows (priority 20) renames the field names to ECS; finally the org overrides at, say, priority 50 add per-tenant table routing.

See also

• Processing Pipelines for the full pipeline grammar, transformation types, and dynamic pipelines.
• Input Formats: EVTX for why these builtins do not match raw EVTX directly.
• backend convert for using builtin pipelines during rule conversion.
• The OCSF pipelines (pipelines/ocsf_postgres.yml, pipelines/ocsf_postgres_multi_table.yml) live in crates/rsigma-convert/pipelines/ and are good copy-paste starting points for non-Windows schemas.