What are Sigma rules?
Sigma is an open standard for signature rule format that allows you to describe searches on log data in generic YAML form. The rule format is easy to write and applicable to any type of log data. The main purpose of Sigma rules is to provide researchers and analysts a structured form in which they can describe their once-developed detection methods and make them shareable with others. Sigma format is one of the common languages of security systems such as EDR and SIEM. According to this format, we can create rules to identify threats.
-jpg.jpeg)
Why do we need Sigma rules?
- One rule for multiple environments: A single rule can be used in environments with multiple configurations. Sigma provides a tool known as sigmac which converts sigma rules to detections for different kinds of SIEMs which can be used in any environment.
- Standardization: The rules follow a specific standard that has to be followed by everyone. One has to make sure that all the standards and specifications are met while writing the rules for detection and the configuration files for the converter. This helps the community to collaborate in a standardized way.
- Each SIEM has its query language: Using sigma rules we can create detection use cases in one syntax and then convert them to any SIEM query language that supports Sigma. This helps analysts to write a rule in Sigma and then use them in any environment of their choice.
- Different fields and ways of ingesting logs: Every system has a different way of ingesting logs and all these fields can be mapped through Sigma rules to support multiple SIEM query languages.
- Share detection content with the community: Being open source, everyone is allowed to use existing rules contributed by the community or have their contribution to the existing rules. This way the whole community comes together to work on detection rules that can be easily shared around and worked with.
How to create sigma rules?
The structure of Sigma rules is made of optional and mandatory parts in a yml structure as follows:
Components:
Log Source
The log source section defines the log data on which the detection has to be applied. It describes the log source, the platform, the application and the type that is required in detection.
- category - examples: firewall, web, antivirus, etc
- product - examples: windows, apache, checkpoint, etc
- service - examples: sshd, applocker, etc
Detection
Detection consists of search identifiers that display searches on log data.
Search-Identifier
A definition that can consist of two different data structures - lists and maps.
List
The list contains all the strings that are to be matched in the logs. The elements of the list are matched with a logical OR operator.
Example: Matches on MaliciousService or malicious.exe -n evil'
detection:
keywords:
- MaliciousService
- malicious.exe -n evil
Map
The map consists of key-value pairs like a dictionary where the key is the field of the log data and the value is the value of that field to be matched in the log data. A logical OR operator joins all elements of the map.
Examples:
Matches on Eventlog 'Evil' and ( Event ID 123 or Event ID 1212 )
detection:
selection:
- EventLog: 'Evil'
EventID:
- 123
- 1212
condition: selection
Condition
This field decides the conditions to be met for any event to trigger. It can allow for a detailed and more complex rule and defenders can use logical operators (for example: AND/OR/NOT) and combine multiple conditions.
False Positives
This consists of a list of known false positives that may occur.
Level
The level includes how critical the detection is based on different levels like low and medium level events which have an informative character, and high and critical level events needing immediate attention from the security analysts.
How to convert sigma rules?
Sigma provides a tool Sigmac which provides us a way to convert sigma rules into supported target SIEM query languages. We have written a backend for converting sigma rules to DNIF query language.
The DNIF HYPERCLOUD backend converts Sigma rules to the DNIF queries, with the identifier as dnif.
This configuration defines value mappings, field mappings and source mappings.
see tools/config/dnif.yml
Example:
For e.g a sigma rule for the recent spark shell command injection CVE-2022-33891 looks something like this:
|
title: Apache Spark Shell Command Injection - Weblogs |
Important blocks for building the detection query:
- logsource:
category: webserver
The log source here is webserver as the detection works on webserver logs.
- detection:
selection:
c-uri | contains: '?doAs=`'
condition: selection
The detection block contains the condition to be met for this rule to trigger. Here the field c-uri in web server logs should contain the keyword "?doAs=`" as it points to the exploitation of the CVE-2014-6287.
So using these important blocks of the sigma rule, the sigma converter is able to convert this rule to DNIF query language (DQL).
# tools/sigmac -t dnif -c tools/config/dnif.yml rules/web/web_cve_2022_33891_spark_shell_command_injection.yml
Output:
stream=webserver where c-uri like "%?doAs=`%"
Conclusion
Sigma rules are well-defined and structured detection rules that can be used with different kinds of environments and systems. It makes the life of security analysts a little better by providing different types of features and options to not only write detection logic effectively but also to share and apply the same rules to different systems.
One rule to rule them all!
DNIF HYPERCLOUD is a SIEM + UEBA solution with automation capabilities.
Click here to know how DNIF's unique approach of threat detection is helping organizations in hunting cyber threats with least alert fatigue and huge cost advantage.
