SEP: Output Fields

[nasbench]

Author(s)

Nasreddine Bencherchali - @nasbench

SEP Type

New Rule Fields (metadata, configuration options)

Abstract

This SEP aims to introduce a new optional field called output_fields that describe which fields should be in the output of a converted detection

Problem Statement

Note: This is re-introduction of the fields field. With increased scope to be called output_fields.

While writing detections, the output fields that an alert produces has to be defined and consistent. The reason being while investigating threats you have to evaluate certain fields in order to gain more context.

For example if the logsource of the detection / alert is a process creation event. An analyst would investigate the Image / Parent / CommandLine at minimum for example.

Also when writing correlations where you use joins or similar operations where you'd have to correlate based on a common fields. That field has to be present in the output in order for this to work across different alerts.

Hence we need a consistent way to describe this.

The fields field answers this, but the name created confusion across users in the past where people used it as suggested investigation fields, others as fields to converted, etc.

This SEP aims to clear this confusion by clearly stating its purpose.

From an implementation point of view. If we take the Splunk backend as an example these will output as | table field1 field2 field3

Use Cases

• Consistent output between alerts
• Ease of correlation

Detailed Specification

Output Fields

Attribute: output_fields

Use: optional

Description:

Defines the fields that must be present in the alert/detection output. These fields are essential for:

• Investigation workflows and threat analysis
• Correlation operations that require common fields across different alerts
• Maintaining consistency in alert output across detection rules
• Ensuring analysts have the necessary context when evaluating alerts

The output_fields attribute explicitly declares which fields the detection rule expects to produce in its output. This is distinct from fields used in the detection logic itself. It specifically defines what information should be available when the rule generates an alert.

The attribute contains a list of field names that should appear in the alert output:

output_fields:
    - FieldName1
    - FieldName2
    - FieldName3

These fields are usually the same across the same logsource and should be defined as part of the taxonomy.

Syntax Examples

title: Suspicious PowerShell Execution
id: 8e3e7bfa-4c4f-4e3f-9b3a-1c8f5d6e7f8a
status: stable
description: Detects suspicious PowerShell command execution patterns
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\powershell.exe'
        CommandLine|contains:
            - 'EncodedCommand'
            - 'WebClient'
            - 'DownloadString'
    condition: selection
output_fields:
    - Image
    - CommandLine
    - ParentImage
    - ParentCommandLine
    - User
    - ComputerName
    - ProcessId
    - ParentProcessId
falsepositives:
    - Administrative scripts
level: medium

Backward Compatibility Impact

Fully backward compatible

Implementation Areas

• YAML structure changes
• Sigma conversion tools (pySigma)
• Backend updates
• Documentation

Submitter Checklist

• I have searched existing issues and SEPs to avoid duplicates
• I have provided concrete examples and use cases
• I have considered backward compatibility implications
• I have thought about implementation complexity

Implementation Assistance

Yes, I can help with implementation

Additional Context

No response

[s-Fl]

Hey, really excited about this change! I'm wondering if there's any chance to make it a bit more advanced by adding a new type of "modifiers" into this output_field section to make it flexible when generating an alert.
I'm using sigma with a custom taxonomy. It includes fields that can have arbitrary values based on fields that occurred in correlated events. Values for those fields can be inserted using so-called set, copy, replace, concat operators and others (I can describe some more operators, if you're interested).

title: Suspicious PowerShell Execution
id: 8e3e7bfa-4c4f-4e3f-9b3a-1c8f5d6e7f8a
status: stable
description: Detects suspicious PowerShell command execution patterns
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\powershell.exe'
        CommandLine|contains:
            - 'EncodedCommand'
            - 'WebClient'
            - 'DownloadString'
    condition: selection
output_fields:
  - set:
      field: MyCustomField
      value: "Custom string"
  - copy:
      from: EncodedCommand
      to: CustomFieldForCommand
  - replace:
      field: Image
      value: "s/\.exe//" # sed expression to remove .exe from the value
      output: NewImage
  - concat:
      fields:
        - Domain # i.e. "example.com"
        - Username # i.e. "th3us3r"
      value: "//" # separator of defined fields
      output: FullName # after concat usage -> "example.com//th3us3r"
falsepositives:
    - Administrative scripts
level: medium