0% found this document useful (0 votes)
78 views13 pages

Sigma Rules

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
78 views13 pages

Sigma Rules

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

Sigma Rules

go2docs.graylog.org/current/what_more_can_graylog_do_for_me/sigma_rules.htm

The following content is part of the Graylog 6.1 documentation. If you are using another
version of Graylog, please switch to your version.

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.

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.

1/13
How It Works
There are three ways to add Sigma rules to Graylog: you can add them manually, import
them from public Git repositories such as the SigmaHQ GitHub repository, or directly
upload them from your local file system. To import Sigma rules from a Git repository, you
first need to add the repo to Graylog.

Add Repository
Hint: Only .yml files are accepted.

1. In Graylog, select the dropdown menu on the Graylog logo and click Security. You
have now changed your view to the Security layout where all your security-related
content is located.

2. Navigate to Sigma Rules > Sigma Repos.

3. Click on the Add Repository button located at the top-right corner of the Current
Repos page.

4. A menu will appear, prompting you to fill out the data fields listed below:

Name: The name of the repository as it will appear in Graylog. This can be
any name, but it must be unique within Graylog.

Branch: A specific branch in the repository can be specified. If left blank, the
Git repository will default to its default branch.

Git Repo URI: The URI of the repository e.g.


https://github.com/MyGitRepo/myrepo.git.

Directories with rules: Allows you to only pull rules from specific directories
within the repository. If left blank the entire repository will be scanned for rules.

5. Click on the Confirm button and Graylog will scan and validate any .yml or .yaml
files found in the repository. Only rules that are properly formatted and supported
will be available for import. Any file that is not .yml will be skipped. All .yml rule files
found will be validated (as in correctly formatted according to the Sigma
specification) so that the rule is supported in Graylog. You will see warnings about
any invalid rules, which will then be bypassed.

6. Once a repository is added, it will appear on the list of current repositories and you
can then import all Sigma rules from that repository or select which rules to import.

During the Add Repository operation, Graylog pulls Git data to the disk of the system
running the Graylog server to populate the list of available rules. Once the operation
completes, the files are removed. By default, the files will be temporarily saved to a temp
directory; however, those with unique system requirements or permissions have the

2/13
option to specify where these files will be saved. This can be done by adding the
Sigma_git_repository_dir entry in your Graylog server configuration file. e.g.
Sigma_git_repository_dir=/etc/graylog/Sigma_data.

Add Sigma Rules Manually


1. In Graylog, select the dropdown menu on the Graylog logo and clickSecurity. You
have now changed your view to the Security layout where all your security-related
content is located.

2. Navigate to Sigma Rules > Rules.

3. Click on the Add Rules button and select Manual Add from the menu options. This
brings up an editor where you can directly create your rule.

4. Complete the process by clicking on the Add Rule at the bottom of the editor to
manually add your rule.

The 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 you attempt to use an
unsupported search modifier or inputs an aggregation in the conditions field, you will
receive a notification that those inputs are not supported.

The Supported Sigma Rule Modifiers and Operators table in the next section provides
you 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 you when creating or importing rules.

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

Import Sigma Rules from SigmaHQ's Repo


1. In Graylog, select the dropdown menu on the Graylog logo and click Security. You
have now changed your view to the Security layout where all your security-related
content is located.
2. Navigate to Sigma Rules > Rules.
3. Click on the Add Rules button and select Import From Git from the menu options.

4. A menu appears next with all available repositories. Select the SigmaHQ repository.

3/13
5. Clicking a repository (and any of its sub directories) will show all valid rules in the
repository available for import. Select the Sigma rule(s) you want to import from the
SigmaHQ repository. Then, click on the Import rules button and the selected rules
will be imported into Graylog.

6. You can also import all rules from the repository by navigating to the Sigma Repos
tab, clicking on the ellipsis to the right of a selected repository and selecting the
Import All option.

Import Sigma Rules from Public Git Repo


In addition to SigmaHQ, you have the option to import Sigma rules from any public Git
repository. All repositories added will appear in the Current Repos page. To import Sigma
rules from repositories other than that of SigmaHQ, follow the steps below:

1. Navigate to Sigma Rules > Rules.

2. Click on the Add Rules button and select Import From Git from the menu options.

3. A menu appears with all available repositories. For this example, we are importing
from the public Git repo, P4T12 Test Repo.

4. Clicking a repository (and any of its sub directories) will show all valid rules in the
repository available for import. Select the Sigma rule(s) you want to import from the
P4T12 Test Repo. Then, click on the Import rules button and the selected rules will
be imported into Graylog.

5. You can also import all rules from the repository by navigating to the Sigma Repos
tab, clicking on the ellipsis to the right of a selected repository and selecting the
Import All option.

4/13
Upload Sigma Rules from Local File System
Along with being able to import Sigma rules from Git repositories, rules can also be
uploaded directly from your file system.

To upload Sigma rules from your local file system:

1. Navigate to Sigma Rules > Rules.

2. Click the Add Rules button and select Upload Rules from the menu options.

3. A menu for uploading Sigma rules from your local file system appears next. You can
upload both individual Sigma YAML files and .zip files containing multiple YAML
files.

4. When you have uploaded your Sigma rules from your local file system, click the
Upload Rules button to complete the upload.

By clicking on an uploaded file in the Selected Files list, you can modify the
streams, notifications, and search configuration for each individual rule. To apply a
configuration to all rules, click the Use these settings on all rules button. When this
configuration is applied, all rules uploaded in a .zip file will have the same
configuration.

When the Sigma rules are uploaded, all successfully imported individual rules will be
removed from the Selected Files list. Any rule that failed to import will remain on the list,
and a reason for the failure displayed. The same process applies in the case of a .zip file
that has invalid rules that cannot be imported, all valid rules will be imported, the failures
will be displayed, and the .zip file will remain on the list.

Manage Rules
Every Sigma rule is automatically associated with an event definition when created;
however, you can edit event definitions by clicking on the ellipsis against the rule to be
modified and selecting the Edit Event Definition option. You can add custom fields and
notifications.

Warning: Do not change the condition type of an event definition. This action breaks the
connection between the Sigma rule and the event definition, and the rule no longer
operates correctly. Changing the event type to either Filter & Aggregation or Correlation
creates 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. These rules can
generate 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.

5/13
From the Sigma Rules page, you can then enable the imported Sigma rules by toggling
the Enable button. You can also use the Bulk Actions feature to enable, disable, or delete
all imported Sigma rules.

Warning: Enabling multiple Sigma rules at the same time, can have a negative impact on
application performance. Hence, a warning message will appear when you attempt to
enable multiple Sigma rules.

When a Sigma rule is imported from Git, it is by default set to run every 5 minutes. You
can change this default setting by clicking on the ellipsis against the Sigma rule, selecting
Edit from the menu options, and changing the default run time.

Manage Imported Repos


From the list of imported repositories located in the Sigma Repos tab, you can perform
the following actions. These actions can be done on a single repository by clicking on the
ellipsis to the right of a selected repository.

Edit: Update the branch or directories from which to source rules.

Import All: Imports all valid rules in a repository into Graylog.

Refresh: Refreshes the list of available rules, if for instance, rules have been added
or changed in the Git repository.

Delete: Deletes the repository metadata from Graylog. The rules will no longer be
available to import, but any rules that were added will remain. Delete can also be
done in bulk by selecting multiple repository check boxes, click theBulk Actions
button and select the Delete option.

All added repositories are shown in the Current Repos page.

Download Sigma Rule Files


You can download Sigma rule files individually or in bulk.

Download Single Sigma Rule File


To download a single rule, simply click on the ellipsis next to the desired rule and choose
the Download option.

Download Multiple Sigma Rule Files

1. To download multiple rules at once, select the rules you want to download and then
click on the Bulk Actions button. From the drop-down menu, select the Download
option.

2. Once you initiate the download, your browser will automatically begin the process.

6/13
It is important to note that, if you choose multiple files, they will be downloaded as a .zip
file containing the rules' .yml files.

Supported Sigma Rule Modifiers and Operators


Graylog Illuminate ships with a lookup table that converts the most common fields present
in Sigma rules from SigmaHQ repository to GIM fields. This conversion allows many rules
to work seamlessly within the Graylog Illuminate processing system. If you want to
customize this lookup table by adding or overriding translations, you can do so by
following the instructions provided in the documentation.

Whenever a search query for Sigma rules is executed, the fields in the Sigma rule are
translated using this lookup table. If the lookup table does not contain a value for a
particular field, the field provided in the Sigma rule is used instead.

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

7/13
Component Sigma Spec Requirement

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

8/13
Special Field Values Current Support

endswith Supported

startswith Supported

utf16le Not Supported

utf16be Not Supported

wide Not Supported

utf16 Not Supported

windash Not Supported

re 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

9/13
Create a Sigma Rule with Regex
Sigma rules with regular expressions (Regex) can be imported or created and used the
same way as any other rule.

Hint: Sigma rules written with Regex must follow the Elasticsearch regular expression
dialect.

Creating a rule by adding the Sigma re modifier to a selection field name will trigger
Graylog to interpret and craft the internal query with Regex. For example:

Copy

detection:
selection:
WorkstationName|re: '^[A-Za-z0-9]{16}$'
condition: selection

This would result in the internal query: WorkstationName: /[A-Za-z0-9]{16}/

A large number of the rules published by SigmaHQ contain regular expressions that are
not technically supported. We have added two cases where Graylog will translate the
rules into Elasticsearch Regex dialect:

1. Digits - \d will be converted to [0-9].

2. Anchors - ^$ e.g. ^<regex>$ - Elasticsearch syntax does not support anchor


characters, but queries are anchored by default. Graylog will remove the
unsupported anchor characters and add wildcards to achieve the same result.

1. ^<regex>$ will be converted to <regex>

2. ^<regex> will be converted to <regex>.*

3. <regex>$ will be converted to .*<regex>

For more information on anchoring, see the Elasticsearch documentation.

Warning: Rules can be created without validating their correct Regex syntax. In this
situation, the rules will succeed in being created but might not achieve the desired results.

Regex Use Case Scenario


Here are some examples of how regex can be used in Sigma rules:

A piece of malware is known to generate a .tmp file with a random eight character
filename in the \Windows\System32 directory. We want to detect file creation for any
.tmp files created in the \Windows\System32 directory that are exactly eight
characters long.

10/13
Copy

detection:
selection:
Image|endswith: '\svchost.exe'
TargetFilename|re: '\\Windows\\System32\\[a-zA-Z0-9]{8}\.tmp$'
condition: selection

An indicator of PowerShell abuse is very long commands. We want to detect any


PowerShell commands that are 1000 characters or longer.

Copy

detection:
selection_powershell:
- CommandLine|contains:
- 'powershell'
- 'pwsh'
selection_length:
CommandLine|re: '.{1000,}'
condition: all of selection*

Assign Alerts to Sigma Rules


You can assign alerts for Sigma rules within the Sigma rules workflow. When you edit a
Sigma rule, a Notifications field with a drop-down menu option appears. If you have
existing alerts configured, they will appear in the Notifications field when creating or
editing a Sigma rule.

11/13
Add Bulk Alerts

When importing one or more rules, you have the ability to add an alerts type in bulk to all
rules by selecting your notification type then click the Use these settings on all rules
button. Alternatively, individual notifications can be selected for each specific rule.

For existing rules, one or more can be selected, then click Bulk Actions > Add
Notification. Here, you can select which notification types to add.

Hint: Note that the bulk add notification feature for Sigma rules is strictly additive; new
notifications are added to existing notifications, and existing notifications for the rules will
remain.

Apply Search Filters and Remediation Steps


When creating or modifying a Sigma rule, you have the options to specify remediation
steps or apply a search filter to the rule.

12/13
Apply Remediation Steps

Graylog Security lets you specify remediation steps (represented as a text value) within
event definitions, sigma rules, and anomaly detectors. This functionality allows you to
outline actionable measures for security analysts to follow when an alert is triggered.
When specified, these remediation steps are prominently displayed upon the triggering of
security events, guiding analysts on the next steps to take.

Apply a Search Filter

Search filters let you reuse query snippets to refine your search result. If you have
properties that you frequently need to either include or exclude from event definitions, you
can create them as search filters, which makes them easy to apply across different event
definitions.

As an example, you may have a list of IP addresses for your internal users. For some
events, you might want to omit this internal activity. You could create a search filter for this
and use it in the event definition to eliminate any messages from those addresses.
Having this query as a search filter lets you reuse it across different event definitions
easily.

For complete information about creating and applying search filters, see Search Filters.

13/13

You might also like