Unveiling the SIGMA (YAML) for Detection Engineering

• Historical background;
• Importance of Sigma Rules in Use Cases;
• Sigma beyond syntax;
• About Sigma Rules itself;
• The main benefits and challenges of Sigma Rules;
• A practical, real-world example we developed.

By the end of the article, we hope the security professional can be convinced of the benefits of using Sigma Rules and start to adopt this format to compose their library of use cases detection.

Historical Background

Before talking about Sigma Rules it’s important to be clear in what context it can be – and even more important – it needs to be used within the threat detection world.

To put a starting point on this story, the Sigma Project emerged in late 2016, created by Florian Roth (Twitter: @cyb3rops) and Thomas Patzke (Twitter: @blubbfiction), offering a standardized format for exchanging files that designate detections, similar to the YARA Rules proposal, however, using log sources as raw material.

A little bit about Use Cases Detection

Also in 2016, the subject of “Use Cases Detection” was already present in international Cyber Defense conferences, being pointed out as a topic, albeit somewhat in its creation process. We’ll cover this with more details in the next article of the series, but for now, it’s important to define what a use case is and how it relates to the Sigma Rule.

An attack scenario assumes several stages the attack must pass through to compromise a system, and therefore several use cases can be implemented to detect and prevent the attack at different stages.

And what does the Sigma Rule have to do with this? Very simple. The use case is at a level of abstraction that cannot be put or written into a rule in SIEM.

The Sigma Rule will be the bridge between these two worlds (or moments). It will be the translation of the design (use case) into a structured language (YAML) that can, in the next step, be materialized into one or more rules for one or more SIEMs targets.

Sigma Beyond Syntax

It’s important to note that when using the Sigma standard, it’s not just a matter of adopting a market solution or making use of a structured notation for documentation purposes that will form part of a knowledge base.

Its structure, and thus its syntax, is just the means by which the detection engineering process is anchored. Materializing a use case by using Sigma Rules should be a simple, objective, and generic proposal to document a threat detection scenario and support the standardization of the Incident Handling process.

Do you know when you discover and learn a new programming language? Well, strictly speaking, knowing how to code is merely part of the process and, if we dare to say it, is of lesser importance when compared to the problem you’re going to solve and how you hope to solve it with that new skill and syntax.

Sigma Rule, therefore, is used (in this case) to document the detection use case.

About Sigma Rules…

Being a generic signature format, Sigma Rule is open and allows you to describe relevant log events straightforwardly, being very flexible, easy to write, and applicable to any kind of log file. This project is currently available via a GitHub called SigmaHQ, which can be accessed here.

The main goal is to provide a structured way in which researchers or analysts can describe their developed detection methods and make them shareable with others. The structure under which Sigma Rule is built, as well as how it works, will be described in the following topics:

• Use case purpose / threat scenario;
• References;
• False Positives;
• Fields;
• Detection logic;
• Metadata.

At the end of the descriptions of each item listed above, we’ll show how the sigma works and the structure in its final version with all these parts contained in the YAML.

Use case purpose/threat scenario: To create a Sigma, the first step is to understand the threat scenario we’re looking at, committing to making a use case. In the chart below we start assembling and describing the sigma with two attributes (title and description). In this example we’re considering a threat scenario that enables the detection of the operating system file deletion, using SDelete, further in this section the title of the detection is described in the title field, and the description field is included in a brief description of the scope of the detection.

title: Sysinternals SDelete Delete File

description: Use of SDelete to erase a file not the free space

References: These are external references used for understanding the threat the detection rule is intended for.

references:

    - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1485/T1485.md

False Positives: Describes possible behaviors that are not exactly a threat, but the rule may wrongly detect for several reasons, such as pentest, administrative actions, automated ones, etc.

falsepositives:

    - System administrator Usage

Fields: Item with a list of fields of the event. These fields are part of the notification (alert) that is sent by the action triggered by the rule in SIEM.

fields:

    - ComputerName

    - User

    - CommandLine

    - ParentCommandLine

Detection Logic: This part describes, in a structured manner, which field/value selection corresponds to the threat pattern to be detected. For the example mentioned we considered in the definition of the data source the use of the logsource field.  This way we were able to discriminate the datasource needed to provide the events and fields used in the detection section, which in turn is composed of a list that shows the event fields with their respective values. In this particular case, illustrated below, to recognize part of the malicious behavior, we specify the value sdelete.exe for the OriginalFileName field (a field that we can find in the Windows process creation log). In the condition field, we can use Boolean operators to relate the specified filters and selections and thus define the final condition on which the rule match depends.

logsource:

    category: process_creation

    product: windows

detection:

    selection:

        OriginalFileName: sdelete.exe

    filter:

        CommandLine|contains:

            - ' -h'

            - ' -c'

            - ' -z'

            - ' /?'

    condition: selection and not filter

Metadata: Here it’s necessary to include control points that define author, creation date, detection version, mitigation, and eradication aspects.

id: a4824fca-976f-4964-b334-0621379e84c4

status: experimental

author: frack113

date: 2021/06/03

With all these elements shown individually, it’s now time to show how it all looks together in one file, in one structure in an integral way with all the fields:

title: Sysinternals SDelete Delete File

id: a4824fca-976f-4964-b334-0621379e84c4

status: experimental

author: frack113

date: 2021/06/03

description: Use of SDelete to erase a file not the free space

references:

    - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1485/T1485.md

tags:

    - attack.impact

    - attack.t1485

logsource:

    category: process_creation

    product: windows

detection:

    selection:

        OriginalFileName: sdelete.exe

    filter:

        CommandLine|contains:

            - ' -h'

            - ' -c'

            - ' -z'

            - ' /?'

    condition: selection and not filter

fields:

    - ComputerName

    - User

    - CommandLine

    - ParentCommandLine

falsepositives:

    - System administrator Usage

level: medium

Translation from Sigma to SIEM

Following the process, now it’s time to do the translation from Sigma to the target SIEM’s search query. To build this flow we use Sigmac, the program responsible for this conversion and translation of a YAML file into the syntax of a target SIEM that can be downloaded here.

For practical purposes, we’ll use an example that is available in the repository of the Sigma Rules project, on Github, at the following path: rules/windows/process_creation/process_creation_SDelete.yml.

The command base for this conversion considers two important parameters: the target (platform the rule is intended to be obtained from Sigma) and configuration file (the parameter used to define the configuration through a file containing the mapping of fields in Sigma); which are used by passing -t and -c, respectively.

We’ll then use Splunk as the target SIEM and, in the configuration file, we’ll use sysmon, hypothetically considering that it’s the log source available in our SIEM. The complete version of the command will look like this:

$ ./tools/sigmac -t splunk -c sysmon rules/windows/process_creation/process_creation_SDelete.yml

After running the sigmac command successfully in the YAML compilation process, the expected output can be seen in the table below.

(EventID="1" OriginalFileName="sdelete.exe" NOT ((CommandLine="* -h*" OR CommandLine="* -c*" OR CommandLine="* -z*" OR CommandLine="* /?*"))) | table ComputerName,User,CommandLine,ParentCommandLine

If you don’t know, or want to find out, what configuration files exist for use in Sigmac use the -l command, which will list all the possible configuration options accordingly:

$ ./tools/sigmac -l




ala : Converts Sigma rule into Azure Log Analytics Queries.

ala-rule : Converts Sigma rule into Azure Log Analytics Rule.

arcsight : Converts Sigma rule into ArcSight saved search. Contributed by SOC Prime. https://socprime.com

arcsight-esm : Converts Sigma rule into ArcSight ESM saved search. Contributed by SOC Prime. https://socprime.com

carbonblack : Converts Sigma rule into CarbonBlack query string. Only searches, no aggregations. Contributed by SOC Prime. https://socprime.com

chronicle : Converts Sigma rule into Google Chronicle YARA-L. Contributed by SOC Prime. https://socprime.com

crowdstrike : Converts Sigma rule into CrowdStrike Search Processing Language (SPL).

csharp : Converts Sigma rule into CSharp Regex in LINQ query.

devo : Converts Sigma rule into Devo query.




...

This output from converting Sigma Rules to an SPL rule can now be implemented in your Splunk SIEM.

Benefits and challenges

“With Sigma, you can leverage your log management solution and apply community-provided detection methods at no extra cost.” — Florian Roth

We can list the following benefits when using Sigma Rules:

Portable: a signature-agnostic format that enables easy migration to other SIEM technologies;

Management in multi-deployment: rules management in environments where the use of two or more SIEMs is mandatory;

No Vendor lock-in: Freedom to change SIEM solutions without losing your intelligence base;

Communication: Agnostic format for expressing detection ideas, therefore enabling the possibility of unambiguous detection exchange between cyber defense professionals;

Community: Use of the contingent production of new detections produced by the cyber defense community.

You may not find a feature that you used in your corporate SIEM, but, make no mistake, that detail will not prevent you from producing the detections you need. We recognize that certain challenges are a reality because sigma will not provide you with some elements that you should consider, such as:

• Rule management;
• Rule testing and quality assurance;
• Automatic documentation;
• Environments and data for testing.

Conclusion

If you work building barriers and detection elements in your customer’s or company’s environment, Sigma Rules could be a very valuable tool to use in your day-to-day work. This mission involves building a vision based on tactics, techniques, and procedures that make it possible to develop a detection logic for threat manifestation.

Structuring the data in a human-readable way will allow you to achieve a more assertive detection. In addition, the possibility of portability to other SIEM technologies also provides an efficiency gain in the use case management process.

And it’s worth mentioning that many of the explanations in this article we have already done at Tempest, through the use of security frameworks such as Cyber Kill Chain®, MITRE ATT&CK, MaGMa, CORAS, among others. We constantly develop use cases focused on threats present in the market and our clients’ business.

The use of the Sigma Rules framework, therefore, becomes an indispensable tool for us to achieve our goals in different environments, detecting new threats with lower false-positive rates and increasing the assertiveness of Tempest’s SOC.