Sigma started with the intention of being a generic format for log signatures. The analyst can describe a pattern for log events in a YAML-based format that will be converted into target query languages of supported SIEM systems. Sigma assumes that the log events are decomposited into key/value pairs which are matched by the rules. One example (excerpt) for such a rule identifies the usage of bitsadmin.exe for downloading files:

logsource:
    product: windows
    service: sysmon
detection:
    selection:
        EventID: 1
        Image:
            - '*\bitsadmin.exe'
        CommandLine:
            - '/transfer'
condition: selection

The Problem

The Sigma converter solves common issues like the usage of different field names in different SIEM solutions and environments by definition of mappings. Simplified, the conversion process is built as follows:

After a while, rules matching two different Windows events appeared that in fact describe the same events. Concretely, process executions in Windows can be expressed by 4688 Security events as well as Sysmon event 1. The first approach to create generic rule files without too much redundancy were Sigma rule collections: A global YAML document defines common parts for both rules and following short YAML documents describe the differences. The rule for invocation of ntdsutil.exe is a good example for such a rule collection.

At first glance, rule collections appeared to be a good solution. Unfortunately, there were some drawbacks:

• Many contributions only contained rules for one event type. This is causing inconsistencies in the rule repository.
• Not all products that were interesting for conversion of Sigma rules into their query language work with log events. One example is Windows Defender ATP that works with tables like ProcessCreationEvents. Similar applies to OSQuery that tracks process executions in a process_events table. For such targets the conversion backend has to map between multiple Windows EventIDs and its specific structures, which is illogical and error-prone. Further products that follow similar concepts exist especially in the EDR product category (Endpoint Detection and Response) and first pull requests with specific rules already appeared.

Creating product-specific Sigma rules doesn't matches well to the goal of generic log signatures.

Solution: Generic Log Sources

Generic log sources will be introduced to solve the issue described above. The above example will be converted to the following Sigma rule:

logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image:
            - '*\bitsadmin.exe'
        CommandLine:
            - '/transfer'
condition: selection

As you perhaps already noticed:

• The EventID matching was removed completely from the rule.
• Instead of referencing the service sysmon in the log source, the category process_creation is used now.

So we get a generic Sigma rule for a suspicious process creation on Windows instead of a Sysmon-specific one.

Enhanced Configurations for the Conversion Process

Obviously, the conversion process into a query must add the information about the event identifier or table. This can happen at different locations:

• Directly in the backend for targets with tables or similar concepts.
• By configuration of the Sigma converter for targets that work with log events.

Until now, Sigma converter supported one configuration file that contains environment or product-specific field name and log source mappings. The Sigma repository and PyPI package contains some common predefined configurations. The following enhancements are currently implemented in the Sigma converter and library:

• Ability to stack multiple configurations.
• A log source definition can now replace the current log source of the rule with a different one. The new log source is then used in further processing of the configuration stack.

With these enhancements, a common configuration may be built as follows:

1. A configuration that maps generic Sigma rules to specific ones, e.g. Sysmon.
2. The configuration that maps log sources to additional conditions and maps Sigma field names to environment-specific ones, e.g. like the Splunk configuration for Windows logs, that is already contained in the Sigma repository.

Therefore, the conversion process would extend as follows:

An example for the first configuration would be:

logsources:
    process_creation:
        category: process_creation
        product: windows
        conditions:
            EventID: 1
        rewrite:
            product: windows
            service: sysmon

This configuration defines that a condition that matches on EventID 1 will be added for all Sigma rules that match the generic log source for Windows process creations. Further, the log source will be rewritten to Sysmon on Windows before it is passed to the second configuration in the stack. The Splunk configuration mentioned above will add another condition that matches the source field to the value WinEventLog:Microsoft-Windows-Sysmon/Operational. Further, the field name EventID will be renamed to EventCode, that is common in most Splunk deployments.

Moving Forward

Within the next weeks, the changes required for supporting stacked configurations will be implemented in the Sigma library and the sigmac conversion tool. Then the existing rules for process creations will be converted to rules with generic log sources.

The changes are developed in the branch project-1 on GitHub. The progress can be tracked on the corresponding project page. You can test the new rules and configurations in this branch and contributions are also welcome, e.g. for consolidation and conversion to generic log source rules. After the implementation and some tests are finished, the changes will be merged into the master branch.

The changes might break current conversion setups if the configuration is not adapted accordingly. On the other side, chances are high that interesting events are missed because some rules only exist for specific event types.