Custom Attributes

Custom Attributes

Sigma rules accept a custom_attributes: mapping for engine and backend hints that aren’t part of the core Sigma spec. RSigma recognizes two namespaces:

• rsigma.*: engine and correlation behavior, mostly per-rule overrides of engine eval and engine daemon CLI flags.
• postgres.*: PostgreSQL/TimescaleDB backend routing, used by backend convert -t postgres to put specific rules on specific tables, schemas, or databases.

CLI flags and library API calls always take precedence over custom_attributes values. Engine-level attributes (rsigma.timestamp_field, rsigma.suppress, rsigma.action) apply only when the CLI did not already set the corresponding flag. Per-correlation attributes always override engine defaults for that rule.

rsigma.* attributes

Example: keep full events for a brute-force rule, default for everything else

title: Brute force login
id: aaaa1111-2222-3333-4444-555555555555
correlation:
    type: event_count
    rules: [failed_login]
    group-by: [User]
    timespan: 5m
    condition: { gte: 5 }
custom_attributes:
    rsigma.correlation_event_mode: "full"
    rsigma.max_correlation_events: 50

Example: longer suppression for a noisy rule

title: PowerShell execution
custom_attributes:
    rsigma.suppress: 30m

rsigma.exemplars

Added in v0.22.0

A list of machine-verifiable example events on a detection or correlation rule. Nested custom_attributes.rsigma.exemplars wins over a top-level dotted rsigma.exemplars key, matching the parser’s existing custom-attribute precedence. Filter rules must not carry exemplars.

custom_attributes:
    rsigma.exemplars:
        - name: whoami fires
          expect: match
          event:
              CommandLine: whoami /all
        - name: benign hostname
          expect: no-match
          event:
              CommandLine: hostname

Each entry accepts exactly these keys:

Exactly one of event or events must be present, and the payload must match the host rule kind. The list itself must not be empty, and unknown keys are rejected. All of these constraints are checked statically by the exemplar_shape and exemplar_wrong_rule_kind lint rules and again by rule test before execution.

Correlation rules use a timestamped events sequence. Each offset is a relative duration string (0s, 30s, 5m) parsed by the existing timespan parser and applied from a fixed base timestamp; offsets must be non-decreasing:

custom_attributes:
    rsigma.exemplars:
        - name: burst of failures
          expect: match
          events:
              - offset: 0s
                event: { EventType: failed_login, User: alice }
              - offset: 30s
                event: { EventType: failed_login, User: alice }

Every exemplar runs with fresh engine state. Detection exemplars evaluate the target rule plus the source collection’s filters. Correlation exemplars load the full collection, including referenced detections and filters. Results are attributed by rule id when present and by title otherwise; an ambiguous fallback title is a configuration error. Optional -p pipelines use the production collection-loading APIs. No logsource routing is enabled implicitly.

A structurally valid expect: match exemplar satisfies ADS validation presence when rsigma.ads.validation prose is absent (N executable exemplar(s)). That is metadata presence, not execution proof. Only a passing rule test proves the current rule still matches.

ADS detection-strategy attributes (rsigma.ads.*)

The rsigma.ads.* namespace carries the Palantir Alerting and Detection Strategy sections that a Sigma rule has no standard home for. These values are pure documentation: the engine never interprets them, so they carry zero runtime cost. Four of the nine ADS sections reuse standard fields (description for the goal, attack.* tags for the categorization, falsepositives, and level for the priority); the rest live here.

Example: a fully documented detection

title: Whoami execution
description: Detects whoami execution, a common discovery step.
status: stable
tags:
    - attack.execution
falsepositives:
    - Administrators enumerating their own privileges
custom_attributes:
    rsigma.ads.strategy: Watch process creation for the whoami binary.
    rsigma.ads.technical_context: Requires process_creation telemetry with CommandLine.
    rsigma.ads.blind_spots:
        - Renamed whoami binaries evade the image match.
    rsigma.ads.validation: Run whoami in a lab and confirm the rule fires.
    rsigma.ads.priority: Medium because discovery sits mid-kill-chain.
    rsigma.ads.response:
        - Confirm the user and host.

Report or scaffold these sections with rsigma rule doc, enforce them in CI with the ads: block documented in the lint-rule reference, and read the full workflow in the Detection Strategy guide.

postgres.* attributes

Used by backend convert -t postgres. The precedence is, from highest to lowest:

1. Rule-level custom_attributes (postgres.table, postgres.schema, postgres.database).
2. Pipeline set_state (key: table, key: schema, key: database).
3. CLI backend options (-O table=..., -O schema=..., -O database=...).
4. Backend defaults (security_events, no schema, no database).

Example: route a process_creation rule to a dedicated table

title: Process Creation
logsource:
    category: process_creation
detection:
    selection:
        CommandLine|contains: 'whoami'
    condition: selection
custom_attributes:
    postgres.table: process_events
    postgres.schema: siem

The generated SQL targets siem.process_events instead of the default security_events.

Other namespaces

The custom_attributes: mapping is namespace-aware: only rsigma.* and postgres.* are interpreted by the engine and PostgreSQL backend. Other namespaces survive parsing but have no behavior attached, so a typo like rsima.suppress is silent. Always lint with rule lint, which flags unknown rsigma.* and postgres.* keys.

See also

• engine eval and engine daemon for the matching CLI flags.
• Processing Pipelines: custom attributes for setting these via set_custom_attribute instead of writing them per rule.
• Rule Conversion: custom table per rule for the PostgreSQL routing flow.
• rsigma-eval README: custom attributes for the library API.