Sigma rules can 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, you can leverage these rules to detect potential threats within your 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 is gaining popularity within the SIEM community and is quickly becoming a common standard for rule interchange. Graylog's Sigma rule processor allows you to connect and import rules from public Git repositories, including the SigmaHQ GitHub repository, providing access to over 2100 supported rules. These rules range from simple and specific to more complex and generic, enabling you to detect suspicious or unusual activity within your Graylog setup by matching Graylog messages against various Sigma rules.
With Graylog and Sigma rules, you can:
-
Import rules directly from the SigmaHQ repository which is publicly accessible on GitHub.
-
Import rules from any public Git repo.
-
Manually add your own rules via a YAML text editor.
-
Download Sigma rule files individually or in bulk.
-
Upload Sigma rules directly from the file system.
-
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 |
|---|---|
|
|
Not Supported |
|
|
Not Supported |
| Value Modifiers | |
|
|
Supported |
|
|
Supported |
|
|
Not Supported |
|
|
Not Supported |
|
|
Supported |
|
|
Supported |
|
|
Not Supported |
|
|
Not Supported |
|
|
Not Supported |
|
|
Not Supported |
|
|
Not Supported |
|
|
Not Supported |
| Expressions | Current Support |
|---|---|
|
Logical |
Supported |
|
|
Supported |
|
|
Not Supported |
|
|
Supported |
|
Negation with |
Supported |
|
Brackets (parenthesis) |
Supported |
|
Wildcards (e.g. |
Supported |
|
Pipe (deprecated) |
Not Supported |
|
Aggregation expression (deprecated) |
Not Supported |
|
Near aggregation expression (deprecated) |
Not Supported |
