Skip to main content

Sigma Rules

Sigma is an open, human-readable rule format used to detect suspicious or malicious behavior through log analysis. Written in YAML and designed to be platform-independent, Sigma rules describe common attack patterns, such as failed login attempts or abnormal PowerShell activity, that can be applied across different security tools and logging systems.

Security Data Lake integrates Sigma rules directly into its event processing engine, allowing incoming logs to be automatically matched against a growing library of threat detection rules. This capability enables real-time alerting and faster incident response, turning threat intelligence into actionable detections.

In this section of the documentation, we review what Sigma rules and Sigma Correlation are; how to add, import, and configure Sigma rules and Correlation; and how to manage or modify existing rules.

Sigma Rules and Security Data Lake

Security Data Lake gives you flexibility in how you work with Sigma rules. Designed to be platform-independent, Security Data Lake allows you to write or add Sigma rules and apply them to your environment. This capability makes these rules highly reusable and easy to share across organizations and teams.

With Security Data Lake, you can:

  • Import rules directly from the SigmaHQ GitHub repository or from any public Git repository.

  • Upload rules from your local file system, individually or in bulk.

  • Create or modify rules using the built-in YAML editor.

  • Clone and customize existing rules to tailor detections to your environment.

  • Schedule executions and associate rules with specific streams for targeted analysis.

  • Correlate multiple rules to detect complex or multi-stage attack scenarios.

Highlights

The following highlights provide a summary of the key takeaways from this article:

  • Security Data Lake supports Sigma rules, a universal YAML-based format, and Sigma Correlation to detect threats through log analysis.

  • Import rules from SigmaHQ or any Git repo, upload rules locally, or create or edit rules in the built-in YAML editor.

  • Each rule auto-generates an event definition, enabling real-time alerts and response workflows.

  • Sigma Correlation expands detection capabilities by identifying patterns that span multiple log events over time.

Sigma Rules and Correlation

Security Data Lake supports two types of Sigma-based detection logic: Sigma rules and Sigma Correlation. Together, this provides both precision and depth for detecting suspicious activity in your log data.

Sigma Rules

A Sigma rule is the basic unit of detection in the Sigma framework. It is designed to identify logs that meet a specific pattern or condition, making them ideal for identifying individual events that might indicate suspicious activity in your environment—for example, a failed login attempt, execution of a known malicious command, or access to a restricted file.

Sigma Correlation

Correlation extends Sigma’s capabilities by analyzing patterns across multiple log events over time. Correlations are ideal for identifying complex, multi-stage attacks that might not be obvious from a single event. They help detect behaviors that require context and accumulation—such as brute-force attempts, privilege escalation, or lateral movement—by linking related events into a cohesive detection.

Security Data Lake supports three Correlation types from the Sigma 2.0 specification:

Correlation Type

Description

event_count

Repeated events from same source (e.g. 10 failed login attempts from the same IP address).

value_count

Variety of values tied to a single field. Triggers when a specific field (e.g. username or source IP) has multiple distinct values in a defined time frame (e.g. The same user account logs in from 5 different countries within 10 minutes).

temporal_ordered

Detects a specific sequence of event types that occur in order within a given time frame (e.g. A user disables antivirus then downloads an executable file).

Create or Add a Sigma Rule

Rules can be added manually via the YAML editor, uploaded files, or imported from a Git repository. Sigma rules and Sigma Correlation automatically generate a corresponding event definition, allowing you to leverage the full range of alerting and automation features in Security Data Lake. See Create or Add a Sigma Rule for more information.

Create or Add a Sigma Rule

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

Security Data Lake supports Sigma rules, which identify specific patterns in individual log events, and Sigma Correlation, which connect multiple related events over time to detect more complex or staged behaviors.

This article explains how to incorporate Sigma rules into Security Data Lake, including how to add them manually, import them from a public GitHub repository, or upload them from your local file system. It additionally covers how to configure and deploy Sigma Correlation.

Methods to Add Sigma Rules

There are three ways to add Sigma rules to Security Data Lake: you can add them manually, import them from public Git repositories like the Sigma HQ Git repository, or directly upload them from your local file system.

Note

Sigma rules may also be enabled via Illuminate packs. See Security Data Lake Illuminate for more information.

Add Rules Manually

Security Data Lake provides a YAML editor which allows you to create custom rules directly within the Security Data Lake UI. To add Sigma rules manually:

  1. Navigate to the Security layout in Security Data Lake or click on the Security tab in the General layout..

  2. Go to Sigma Rules > Rules.

  3. Click Add Rules , then select Manual Add.

  4. Use the YAML editor to create or paste a Sigma rule.

  5. Enter the required configuration values in the fields below:

    • Streams: Set this to the stream that contains your events (e.g., windows-security-logs or auth-logs) so the rule evaluates the correct log source.

    • Stream Categories: This helps when filtering or organizing at scale.

    • Notifications: You can bind this rule to a notification, to receive email, Slack message, or webhook when an alert it triggered.

    • Search Within: This field specifies the timeframe used to evaluate events.

    • Use Cron Scheduling: Toggle the cron scheduling option to automate the process of running an event, making it possible to run events periodically at a fixed time, date, or other interval.

      • Cron expression: A cron expression is a string of fields separated by white space. Security Data Lake uses Quartz cron syntax, for example:

        <second> <minute> <hour> <day of month> <month> <day of week> <year>

    • Execute Every: Rule runs every 5 minutes to check if it matches. This can be adjusted based on need.

    • Search Filters: Add search filters for more specific matching without changing YAML (e.g., only count failures on domain controllers).

    • Remediation Steps: Include specific, actionable instructions (represented as a text value) to resolve an identified issue.

  6. Click Add Rule to finalize.

The editor notifies 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 input an aggregation in the conditions field, you receive a notification that those inputs are not supported.

Review the supported Sigma rule modifiers and operators table for currently supported features, rule specifications, fields required by Security Data Lake that might not be required by the Sigma specifications, and unsupported conditions and modifiers.

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

Import Rules from the Public GitHub Repository

To import Sigma rules from a Git repository, you first need to add the source repository to Security Data Lake. In this example, we'll be importing from SigmaHQ's public GitHub repository.

Add SigmaHQ Repository to Security Data Lake

  1. Navigate to the Security layout in Security Data Lake.

  2. Go to Sigma Rules > Sigma Repos.

  3. Click the Add Repository button.

  4. Fill in the repository details:

    • Name: Enter a unique name for the repository (e.g. SigmaHQ).

    • Branch: Specify a branch or leave blank for the default.

    • Git Repo URI: URL of the repository (e.g. https://github.com/MyGitRepo/myrepo.git).

    • Directories with rules: Specify directories or leave blank to scan the entire repository.

  5. Click Confirm.

    Security Data Lake scans and validates all .yml or .yaml files found in the repository. Only rules that are properly formatted (according to the Sigma specification) and supported are validated and available for import. Any file that is not .yml is skipped.

  6. Import all Sigma rules from the added repository or select which rules to import. When a repository is added, it appears on the Sigma Rules GIT Repos page.

When you add a repository, Security Data Lake pulls Git data to the disk of the system running the Security Data Lake server to populate the list of available rules. After the operation completes, the files are removed. By default, the files are saved to a temporary directory; however, users with unique system requirements or permission constraints can choose a custom location for storing these files. You can change the directory by adding the Sigma_git_repository_dir property to your Security Data Lake server configuration file with the location of your rule repository, e.g. Sigma_git_repository_dir=/etc/graylog/Sigma_data.

Import Rules from GitHub Repository

Leverage existing, community-maintained rules by connecting to public repositories like the SigmaHQ GitHub project. Security Data Lake can scan the repository, validate supported rule files, and allow you to selectively import or bulk-add them into your environment.

Once the repository is added:

  1. Navigate to the Security layout in Security Data Lake.

  2. Go to Sigma Rules > Rules.

  3. Click the Add Rules button, then select Import From Git.

  4. Select the SigmaHQ repository from the list of available repositories in the window that appears.

  5. Locate and select the rules to be imported within the sub directories of the SigmaHQ repository.

  6. Click Import rules. The selected rules are imported into Security Data Lake.

    Select Rules.png

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.

Upload from a Local File System

If you already have Sigma rules stored locally or exported from another system, you can upload them directly into Security Data Lake.

  1. Navigate to the Security layout in Security Data Lake.

  2. Go to Sigma Rules > Rules.

  3. Click the Add Rules button, then select Upload Rules from your local file system.

  4. Upload individual Sigma YAML files or .zip files containing multiple YAML files.

  5. Click Upload rules to complete the process.

Create a Sigma Rule with Regex

Sigma rules with regular expressions (Regex) can also be imported or created and used the same way as any other rule.

Note

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 Security Data Lake to interpret and craft the internal query with Regex. For example:

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 Security Data Lake 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. Security Data Lake 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.

Note

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

Regex Example

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:

    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:

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

Enable Sigma Rules

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

Create Sigma Correlation

Warning

Currently, Security Data Lake does not support the multi-document file format, where all correlated rules and the Correlation itself are included in a single .yml or .yaml file separated by three hyphens. Each rule must be added in its own YAML file. Similarly, Security Data Lake does not currently support the aliases field used to aggregate across different fields in different event types.

After creating your Sigma rules, you can enhance your detection coverage by configuring Sigma Correlations to detect multi-stage or chained threat activities. The process for adding a Correlation follows the same steps as adding standard Sigma rules. You can create one manually, import it from a public Git repository, or upload it from your local file system. Once added, you'll need to define the correlation logic that determines how individual events are linked, based on timing, field relationships, or shared attributes.

Correlate Events with event_count

When using event_count or value_count Correlation, the Sigma rule used for aggregation does not need to be enabled. This Correlation utilizes the rule solely to generate the underlying query logic and does not rely on the rule being active or generating events.

For example, to create an event_count Correlation that identifies multiple failed login attempts by a user, you would first define a Sigma rule that specifies the search conditions for a failed login event.

A rule meeting that criteria may look as follows:

title: Many failed logins
id: 0e95725d-7320-415d-80f7-004da920fc22
correlation:
    type: event_count
    rules:
        - failed-logon-attempt
    group-by:
        - user_name
    timespan: 5m
    condition:
        gte: 5
level: high
status: experimental

The rule is created to detect multiple failed logins and the YAML composition is explained as follows:

  • type: event_count

    • This parameter defines the type of Sigma correlation rule.

  • rules: failed-logon-attempt

    • This refers to a predefined detection Sigma rule name, think of it as the rule's logic source. It is the "name" field in the sigma rule, not "title". Also, the "id" of the rule can be used here as well.

  • group-by: user_name

    • The correlation is scoped per user. Security Data Lake will count failed attempts per user.

  • timespan: 5m

    • The window to evaluate the events. In this example it is 5 minutes.

  • condition: gte: 5

    • If there are 5 or more matching events within that 5 minute window per user, the rule will trigger.

The level and status values are used for metadata, helpful for filtering and understanding the rule.

Note

The timespan parameter in Sigma Correlation is required by the specification. However, within Security Data Lake, it is optional and is not used to configure the Search within field. The Search within configuration option is used when performing Correlations regardless of whether a timeframe is specified in the rule.

Correlate Events with temporal_ordered

When using temporal_ordered Correlations, the form is slightly different, as streams and search filters are not relevant. Those two fields are removed when a temporal_ordered rule is detected. When using temporal_ordered Correlation, all referenced rules must be enabled because the Correlation engine only works if each rule can actively generate events.

Because aliases are not supported, all rules in the sequence must use the same group-by field. The group-by field is used as the event key by the correlation engine to correlate events on the same field.

You can group results using any field in your data that has been indexed as a keyword or IP address.

temporal_ordered Example

In this scenario imagine you want to detect a successful login immediately after multiple failed attempts from the same user.To do this, you need two Sigma rules:

  • many-failed-logins: Detects 5+ failed logins by the same user in 5 minutes.

    title: Many failed logins
    name: many-failed-logins
    id: 0e95725d-7320-415d-80f7-004da920fc22
    correlation:
        type: event_count
        rules:
            - failed-logon-attempt
        group-by:
            - user_name
        timespan: 5m
        condition:
            gte: 5
    level: high
    status: experimental
  • successful-login: Detects a successful login by that same user.

    title: Successful Login After 5 Failed Attempts
    id: 0e95725d-beef-415d-80f7-004da920fc22
    correlation:
        type: temporal_ordered
        rules:
            - many-failed-logins
            - successful-login
        group-by:
            - user_name
        timespan: 1m

You then configure a temporal_ordered Correlation titled Successful Login After 5 Failed Attempts, which refers to both the many-failed-logins and successful-login rules. This Correlation uses user_name as the group-by field and has a timespan of 1 minute, meaning the successful login must occur within one minute after the failed attempts for the correlation to trigger.

title: Successful Login After 5 Failed Attempts
id: 0e95725d-beef-415d-80f7-004da920fc22
correlation:
    type: temporal_ordered
    rules:
        - many-failed-logins
        - successful-login
    group-by:
        - user_name
    timespan: 1m

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.

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.

Note

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.

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 more information about creating and applying search filters, see Search Filters.

Supported Sigma Rule Modifiers and Operators

Security Data Lake Illuminate contains 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 Security Data Lake 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.

Components

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

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

Supported

Expressions

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

Manage Sigma Rules

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.Graylog Security

Sigma rules and Sigma Correlation help detect threats by matching log events against known attack patterns. After you add rules to Graylog, you can manage and maintain them using Graylog’s built-in tools to ensure your detection logic stays organized, up to date, and aligned with your monitoring strategy.

This article focuses on the management aspects of Sigma rules and repositories within Graylog

Manage Rules

All imported and user-defined Sigma rules are displayed in a table on the Sigma Rules page. Each entry includes key metadata such as the rule’s description, operational status, and configuration parameters. The Enabled column contains a toggle switch that allows you to enable or disable each rule.

  • Enabled: Rule runs on its defined schedule.

  • Disabled: Rule is inactive and does not evaluate logs or generate alerts.

To manage your Sigma rules:

  1. Navigate to the Security layout in Graylog.

  2. Go to Sigma Rules > Rules.

  3. Select the ellipsis () next to a selected rule and choose the desired action from the menu options. From here, you can:

Edit Rule

To modify an existing rule:

  1. Click the ellipsis () next to the rule.

  2. Select Edit from the menu options.

  3. Update YAML definitions, metadata, associated streams, or execution schedules.

  4. Click Save changes to update the rule.

    Note

    Sigma rules from Illuminate packs derive their rule logic and configuration settings from the content packs, so you can only edit these rules to add notifications and filters but not the actual rule logic.

Clone Rule

If you want to create a variant of an existing rule:

  1. Click the ellipsis () next to the rule.

  2. Choose Clone from the menu options.

  3. Edit the cloned rule’s contents to customize it.

  4. Save the new rule with unique metadata or correlation logic by clicking the Add rule button.

This capability is useful for adapting standard rules to specific environments. The new rule can be modified independently without affecting the original.

Download Rule

  1. Click the ellipsis () next to the rule.

  2. Select Download from the menu options. The rule is downloaded as a .yaml file.

This functionality is useful for backups, offline review, transferring rules between environments, or sharing with teams.

Edit Event Definition

Every Sigma rule is automatically associated with an event definition when created; however, you can edit event definitions by:

  1. Click the ellipsis () next to the rule.

  2. Select Edit Event Definition from the menu options. This action opens the associated event definition used for alerting when the rule is triggered.

  3. Modify remediation notes attached to the event definition, add custom fields, and edit notification settings.

Warning

Do notchange 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 Correlationcreates a completely different event definition.

Delete Rule

This action permanently deletes the rule from Graylog. Before deletion, Graylog prompts for confirmation.

Warning

Deleting a rule also removes its detection logic and disables any linked alerts.

Bulk Actions

Use the check boxes on the left to select multiple rules, then apply bulk actions. The following functionality is available for bulk actions: enable, disable, add notification, download, and delete.

Note

Note that the bulk Add Notificationfeature is strictly additive. New notifications are added to existing rules, and existing notifications for the rules remain.

Manage Repositories

From the list of imported repositories located in the Sigma Repos tab, you can perform the following actions. These actions can be performed on a single repository by clicking the ellipsis to the right of a selected repository, then selecting the required action from the options listed below.

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

  • Import All: Imports all valid rules from 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 remain. Delete can also be done in bulk. Select multiple repository check boxes, click the Bulk Actions button, then select Delete.

All added repositories are shown in the Sigma Rules GIT Repos page.