Directly interact with savedsearches.conf fields when using the savedsearches format

[joshnck]

Take the following rule and example:

title: Suspicious DNS Query with B64 Encoded String
id: 4153a907-2451-4e4f-a578-c52bb6881432
status: experimental
description: Detects suspicious DNS queries using base64 encoding
author: Florian Roth - modified by Josh Nickels for internal use
date: 2018/05/10
modified: 2022/09/20
references:
    - https://github.com/krmaxwell/dns-exfiltration
logsource:
    category: dns
detection:
    selection:
        query|contains: '==.'
    timeframe: 2h
    condition: selection
falsepositives:
    - Unknown
level: medium
fields:
    - query
    - host
    - src_ip
    - dest_ip
tags:
    - attack.exfiltration
    - attack.t1048.003
    - attack.command_and_control
    - attack.t1071.004

sigma convert --without-pipeline -t splunk -f savedsearches rule.yml

outputs:

[default]
dispatch.earliest_time = -30d
dispatch.latest_time = now

[Suspicious DNS Query with B64 Encoded String]
description = Detects suspicious DNS queries using base64 encoding
search = query="*==.*" \
| table query,host,src_ip,dest_ip

I would like to modify this on a per-rule basis to give me the ability to modify the cron_schedule or alert.suppress.fields: without having to modify the pipeline for each rule. This is of course possible in postprocessing in the pipeline, and I can do some logic like "if rule contains the word query, then set alert.suppress.fields to query" or something but that isn't always possible or scalable.

We've solved this by adding an optional custom section to our Sigma rules like this:

splunksigma:
    backend:
        args:
            action.notable.param.security_domain: endpoint
            cron_schedule: '06 1-23/2 * * *'
            alert.suppress: 1
            alert.suppress.fields: host

Which works fine for us and we can directly call the savedsearches.conf field names by name to modify the output. But I think this is likely a problem that other teams have and I'd be curious on if this is something that could be implemented into the backend.

It would of course deviate from the Sigma standard specifications but just appending the savedsearches.conf fields into the rules and having them interpreted by the backend during conversion would be powerful.

The ideal state is that the output is:

[default]
dispatch.earliest_time = -30d
dispatch.latest_time = now

[Suspicious DNS Query with B64 Encoded String]
action.notable.param.security_domain: endpoint
cron_schedule: '06 1-23/2 * * *'
alert.suppress: 1
alert.suppress.fields: host
description = Detects suspicious DNS queries using base64 encoding
search = query="*==.*" \
| table query,host,src_ip,dest_ip

[thomaspatzke]

Using the output format of a backend is not the recommended way anymore to support such formats like Splunk savedsearches.conf files. Instead, as you mentioned, query postprocessing is the way to go due to it's flexibility compared to the output format.

The Jinja2 templates in query post-processing should be able to access custom attributes with {{ rule.custom_attributes.cron_schedule }} etc. This is also totally fine from Sigma specification point of view because Sigma is extensible by custom attributes by spec.