What Are Sigma Rules?

In this article, we delve into Sigma Rules, a powerful cybersecurity tool used for creating and sharing detection methods across various Security Information and Event Management (SIEM) systems.

We will explore the fundamental concepts of Sigma Rules, how they standardize threat detection, and their significance in the ever-evolving cybersecurity landscape. Additionally, we will examine an example of Sigma Rules, including its structure, syntax, and essential components to guide you through writing your first sigma rule. Finally, we will look at common mistakes made during the development of a sigma rule. You can also refer to our blog post about Yara Rules which is another widely used framework.

What Is Sigma Rule?

A Sigma rule is an open-source, generic signature format used in cybersecurity, specifically for the creation and sharing of detection methods across Security Information and Event Management (SIEM) systems. Sigma rules translate and standardize threat-detection practices, making them accessible and reusable regardless of the SIEM platform in use.

Similar to how YARA rules use Indicators of Compromise (IoC) to aid in the identification and classification of malware instances, Sigma rules match specified criteria to log events, to facilitate incident detection. 

Sigma rules are written in YAML syntax, which is a human-readable and easy-to-implement format. Once you have written a Sigma rule, you can convert it to a format that fits your target SIEM or platform using an online converter. There are many different platforms that support Sigma rules, including Splunk, Elasticsearch, and Microsoft Defender. 

A Sigma rule can contain a variety of elements, including:

• Title: A brief, precise description of the detection principle.

• Status: This could be "experimental," "tested," etc., indicating the stage of rule development.

• Description: An elaborate explanation of what the rule is designed to detect.

• Author Name: The name of the creator of the rule.

• Date: The date when the rule was created.

• ID: A unique identifier assigned to the rule.

• License: The terms under which the rule can be used, provided the author shares the rule.

• Level: The severity or priority level of the Sigma rule.

• Data or Log Source: The origin or type of data that the rule applies to.

• Set of Conditions: The specific criteria or patterns that the rule looks for.

• Tags: The rule can additionally be tagged with identifiers such as MITRE ATT&CK mapping, which provides a common nomenclature for cyber threat behavior.

What Are the Benefits of Using Sigma Rules?

There are four main benefits that the use of sigma rules offers.

• Standardization

Sigma rules provide a universal language that security analysts can use regardless of the Security Information and Event Management (SIEM) or log management system being implemented. This standardization simplifies log parsing and rule creation, as Sigma rules need to be written once and can then be automatically translated for use with various platforms, thereby enabling a more efficient use of resources and maximizing analysts' productivity.

• Collaboration

Sigma rules offer a shared platform for cybersecurity experts to work together and enhance their detection capabilities. 

An open-source nature allows for Sigma rules to be shared and refined via platforms like GitHub, fostering a communal environment that encourages the exchange of knowledge and ideas. The shared repository reduces redundancies and allows for the collective knowledge to better the cybersecurity industry as a whole.

• Skill Development

By exchanging ideas and Sigma rules across the cybersecurity community, the environment fosters a culture of shared learning. Both novices and experts alike can contribute to and learn from this communal knowledge base, bridging the cybersecurity skill gap. The broader sharing of Sigma rules facilitates the sharing of novel detection techniques, fostering constant growth and development among security analysts.

• Flexibility & Cost Efficiency

Sigma rules allow organizations to evolutionize their cybersecurity defensive measures in a way that best suits their needs and budgets. 

The ability to convert Sigma rules to any vendor format grants security teams the flexibility to migrate from one SIEM system to another seamlessly, without losing the value of existing rules. This feature can help organizations avoid the trap of vendor lock-in and also make it easier for them to scale their cybersecurity operations with changing needs.

How to Write Sigma Rules?

In this section, we will provide you with an example sigma rule that will guide you through writing your first sigma rule. This example will include corresponding elements within its body.

The sigma rule that we are about to dissect is designed to detect the attempt of SharpSecDump usage, a credential harvesting tool, ported from python/impacket to .net. This technique is commonly utilized for credential dumping. Adversaries may attempt to dump credentials to obtain account login and credential material, normally in the form of a hash or a clear text password, from the operating system and software [1].

An Example: A Sigma Rule to Detect the Attempt of SharpSecDump Usage for Credential Dumping

Code 1. An Example Sigma Rule Developed by Picus Security 

We will delve deeper into the technical aspects of the Sigma rule:

• Title

The title indicates that the rule aims to detect Credential Dumping using the tool named 'SharpSecDump'.

• Status

The status is 'experimental', which means this rule is in the testing phase and may not yet be provably reliable in a production environment.

• Description

This provides more context. It describes adversaries' intention behind employing SharpSecDump -- to dump valid account credentials, either in hashed or plaintext forms.

• Author and References

The rule was written by Picus Security. The references link to sources, which help substantiate the technique addressed in the rule and provide more background information on the threat.

• Logsource

Every Sigma rule must specify the sources of logs it analyzes. This particular rule is designed to read logs from the 'security' service on Windows systems. This typically implies auditing security events sourced from the Windows Event Log service.

• Definitions 

They outline the auditing settings necessary for the creation of log events required for this detection rule to function correctly. 

Definition 1: This definition specifies that the Group Policy setting for Audit Process Creation under Advanced Audit Policy Configuration should be set up. 

The broader policy path is Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\Detailed Tracking\Audit Process Creation. 

Here's what this means:

The Audit Process Creation policy setting enables auditing of each event of process creation on a system. This is crucial for this Sigma rule because it's designed to detect instances where the SharpSecDump tool is used to create a new process for credential dumping. This policy setting will capture and log each instance of process creation, including who initiated the process and what program was started.

Definition 2: This definition indicates another Group Policy setting that is needed: Include Command Line. The path for this policy is Computer Configuration\Administrative Templates\System\Audit Process Creation\ Include Command Line. 

Here's why this is significant:

The Include Command Line policy setting, when enabled, ensures that the command line input that was used to launch the process is included as part of the audit event. This is vital for detecting SharpSecDump usage, which is identifiable by its command line signature (*sharpsecdump*). 

So, this policy setting provides the necessary details in the logs to match with the command line pattern this Sigma rule is looking for.

• Detection

'EventID' represents the specific Windows event that the rule searches within. '4688' corresponds to an event where a new process has been created. 'ProcessCommandLine' represents the exact command used to initialize the program in question. A detection of 'sharpsecdump' in ProcessCommandLine infers that the SharpSecDump tool has been executed.

• Condition

This is the crux of the rule. If the conditions specified within 'selection' (i.e., EventID: 4688 and ProcessCommandLine: 'sharpsecdump') are met in the logs, the rule will be triggered.

• False Positives

No rule is fail-safe. While there isn't a specified list of scenarios that could result in false positives, recognizing the possibilities for such occurrences helps analysts use their judgment when alerts are triggered.

• Level

'High' signifies the rule is meant to find serious security threats. Alerts triggered by this rule should be prioritized over those of medium or low levels.

• Tags

They serve to categorize the rule by mapping to known cyber attack techniques. 'attack.credential_access' falls under the tactic of Credential Access in the MITRE ATT&CK framework showing that the rule is aimed at detecting attempts to steal login credentials.

Therefore, this Sigma rule is a useful detective control against attempts to dump credentials using the SharpSecDump tool—an activity often associated with an attacker who has already gained initial access and is now trying to escalate privileges or move laterally within the network.

Common Mistakes in When Writing a Sigma Rule

Sigma rules, while highly effective, can be prone to errors if not written carefully. Here are some common technical pitfalls:

• Case Sensitivity 

Sigma rules are predominantly case-insensitive, except when regular expressions are used. Confusion around this can cause false negatives where threats go undetected due to case mismatches.

• Backslash Misuse

Errors often arise from incorrect backslash usage when escaping strings – particularly in regular expressions. Single backslashes shouldn't be escaped (e.g., 'C:\Windows\System32\cmd.exe'). 

On the other hand, a group of backslashes or wildcard characters ('', '?') require escaping (e.g., '' results in ' '; to have an actual '' or ' ', use '' or ' ').

• Logical Operators' Misuse 

Misusing Boolean operators ('AND', 'OR', 'NOT') when forming the rule's conditions may lead to erroneous evaluations. 

For example, using an 'OR' operator when the logic requires an 'AND' could trigger false alerts. The complexity multiplies when these operators combine multiple selection criteria, thus understanding their correct usage is essential for accurate Sigma rule creation.

SIEM Platforms Supported by Sigma Rules

Sigma can be used with these log sources in a variety of ways. 

For example, Sigma can be used to create Splunk searches that detect threats. To do this, you would need to create a Sigma rule that defines the criteria for detecting a threat. Once you have created the Sigma rule, you can import it into Splunk and run it against your Splunk logs. If the Sigma rule matches any of your logs, Splunk will generate an alert.

Here are the top 15 Sigma targets.

• Splunk

• Elasticsearch

• Microsoft Defender

• Logpoint

• Azure Sentinel / Azure Log Analytics

• Sumologic

• ArcSight

• QRadar

• Qualys

• RSA NetWitness

• PowerShell

• Grep

• LimaCharlie

• ee-outliers

• STIX