Create or Add a Sigma Rule

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

• You must have a Graylog Security license.

• Graylog 4.3 or higher is required for Sigma rules.

• Graylog Illuminate is recommended for use with Sigma rules and Sigma Correlation.

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.

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: 

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.

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

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

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.

  Copy

  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.

  Copy

  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.

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 Remediation Steps

You can 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 you on the appropriate next steps to take.

For more information, see Remediation Steps.

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

• Sigma Rules

• Manage Sigma Rules

• Graylog Security

• Event Definitions