The following article exclusively pertains to a Graylog Security feature or functionality. Graylog Security is a part of the Graylog centralized log management platform and requires a separate license. Contact the Graylog Sales team for more information on this product.

With Graylog 5.0, Sigma rules can now be imported and executed within the Graylog event processor. Sigma is a generic and open signature format that allows for the detection of suspicious or malicious activity. By importing Sigma rules into Graylog, users can leverage these rules to detect potential threats within their environment.

Sigma rules are YAML text signatures that enable you to identify suspicious events in your environment by matching log events that might indicate adversarial behavior or cyber threats. These rules are essentially a collection of “search scripts” used to identify specific threats within your IT environment.

The Sigma rule format has gained popularity within the Security Information & Event Management (SIEM) community and is quickly becoming a common interchange for rules.

Graylog’s Sigma Rule Event Processor allows users to connect to the SigmaHQ GitHub repository and make use of the 2100+ supported rules ranging from simple and specific to more complex and generic rules. This offering makes it possible for users to detect and alert on suspicious or unusual activity in their Graylog setup by matching Graylog messages against a variety of Sigma rules.

With Graylog’s Sigma Rule Event Processor, users can:

  • Import rules directly from the SigmaHQ repository which is publicly accessible on GitHub.

  • Manually add their own rules via a YAML text editor.

  • Clone an existing rule.

  • Associate a rule with 1 to N streams in Graylog.

  • Define how often and over what time window the rule should run.

How It Works

Sigma rules can be added manually or imported from the SigmaHQ GitHub rep.

Sigma rules can generate very resource-intensive queries that could potentially stress or crash the search backend. Some rules use wildcard queries, which are not moderated or flagged as they are elsewhere in Graylog. In order to test the performance of individual rules, we recommend you use the search logs option before activating the Sigma Rule.

Import Sigma Rules from SigmaHQ's Repo into Graylog's Sigma Rule Event Processor

  • From your Graylog interface, navigate to the Security tab and select Sigma Rules from the left-pane menu.

  • In the resulting page, click on the Add Rule button and select Import From Git.

  • Select the Sigma rule(s) you want to use from the SigmaHQ repository. Then, confirm your selections, and the selected rules will be imported into Graylog.

  • Every Sigma rule is automatically associated with an event definition when created; however, users can edit event definitions by clicking on the ellipsis against the rule to be modified and selecting the Edit Event Definition option. Users can add fields and notifications and change the title, description, and priority.

Do not change the condition type of an event definition. This will break the connection between the Sigma rule and the event definition, and it will no longer operate correctly. Changing it to either Filter & Aggregation or Correlation will create a completely different event definition.

Each Sigma rule imported into Graylog can also directly execute as a search, which can help both when writing new rules as well as understanding existing ones.

From the Sigma Rules page, users can then enable the imported Sigma Rules by toggling the enable button. Users can also use the Bulk Actions feature to enable, disable, or delete all imported Sigma Rules.
(When a Sigma Rule is imported from Git, it is by default set to run every 5 minutes). Users can change this default setting by simply clicking on the ellipsis against the Sigma Rule, selecting Edit from the menu options, and changing the default run time.

Manually Add Sigma Rules to Graylog's Sigma Rule Event Processor

  • From your Graylog user interface, navigate to the Security tab and select Sigma Rules from the left pane menu.

  • On the resulting page, select Manual Add. This brings up a YAML editor where you can either directly make your rule(s) or copy from the Sigma Git repository and paste it into the editor. The YAML editor will notify you if required fields are missing (e.g. title) or if a field should be of a certain type (e.g. string) before you attempt to save and exit. If a user attempts to use an unsupported search modifier or inputs an aggregation in the conditions field, they will receive a notification that those inputs are not supported.

These notifications help guide users when creating Sigma rules.

Our Sigma Rules (GL 5.0) Supported Sigma Rule Modifiers and Operators table in the next section provides users with currently supported features, rule specifications for Graylog, fields required by us that might not be required by the Sigma specifications, and conditions and modifiers we do or do not support. This will help guide users when creating or importing rules so they know which ones are compatible with Graylog. 

When you create Sigma Rules, an event definition will also be created. This is because events need streams (optional streams) and search windows (to know over what time window and how frequently to search) in order to function properly. These options are configurable on the user interface and can also be specified in the YAML editor.

Supported Sigma Rule Modifiers and Operators

Graylog Illuminate ships with a lookup table that will translate some of the most common fields found in Sigma rules within the SigmaHQ repository into GIM fields. This will allow many rules to work seamlessly within Graylog Illuminate processing. If those translations need to be overridden or added to, the lookup table can be customized. Refer to the Lookup Table Customization documentation for more information. Fields in the Sigma rule will be translated using this lookup table each time a Sigma rule search is executed. If no value exists in the lookup table, the field provided in the Sigma rule itself will be used.

Component Sigma Spec Requirement
Title

required

Id

optional

Related

optional

Status

optional

Description

optional

Author

optional

References

optional

Log Source

required

Category

optional

Product

optional

Service

optional

Definition

optional

Detection

required

Search-Identifier

optional

{string-list}

optional

{field: value}

optional

Timeframe

optional

Condition

required

Fields

optional

False Positives

optional

Level

optional

Tags

optional

[arbitrary custom fields]

optional

 

Special Field Values Current Support

'' (Empty Value)

Not Supported

null

Not Supported

Value Modifiers

contains

Supported

all

Supported

base64

Not Supported

base64offset

Not Supported

endswith

Supported

startswith

Supported

utf16le

Not Supported

utf16be

Not Supported

wide

Not Supported

utf16

Not Supported

windash

Not Supported

re

Not Supported

 

Expressions Current Support

Logical AND/OR

Supported

1/all of search-identifier

Supported

1/all of them

Not Supported

1/all of search-identifier-pattern

Supported

Negation with 'not'

Supported

Brackets (parenthesis)

Supported

Wildcards (e.g. selection*)

Supported

Pipe (deprecated) |

Not Supported

Aggregation expression (deprecated)

Not Supported

Near aggregation expression (deprecated)

Not Supported