A typical corporate network consists of hundreds or thousands of devices generating millions of log lines every minute. What then can enable SOC and threat intelligence analysts to effectively sift through all this flow of information and separate malicious activity from everyday noise in an automated fashion?
This is where Sigma rules come in handy.
What are sigma rules?
Sigma rules are text signatures written in YAML that help detect anomalies in your environment by monitoring log events that can be signs of suspicious activity and cyber threats. Developed by threat intelligence analysts Florian Roth and Thomas Patzke, Sigma is a generic signature format for use in SIEM systems. One of the main advantages of using a standardized format like Sigma is that the rules are cross-platform and work on different Security Information and Event Management (SIEM) products. Thus, defenders can use a “common language” to share detection rules independent of their security arsenal. These Sigma rules can then be converted by SIEM products into their own SIEM language, while retaining the logic conveyed by the Sigma rule.
While among analysts, YARA rules are more often associated with identifying and classifying malware samples (files) using indicators of compromise (IOCs), Sigma rules focus on detection log events that match the criteria defined by the rule. Incident response professionals, for example, can use Sigma rules to specify certain detection criteria. Any log entry matching this rule will trigger an alarm.
The Sigma specification
The possibilities offered by Sigma are vast and therefore it is useful to familiarize yourself with the Sigma specification. It offers a long list of fields and defines what each means:
Source: Sigma GitHub repository
From basic metadata fields such as rule name and author to functional fields such as time period, channel id and log source, Sigma rules allow for advanced monitoring of events and log entries .
How to Write a Sigma Rule
Each Sigma rule must have a title and an identifier. The title field briefly describes what the rule is supposed to do in up to 256 characters. The id field is assumed to contain a globally unique identifier for the rule. Typically, the id field is specified as a randomly generated universally unique identifier (UUID) value.
The status field specifies whether the rule is considered stable for use in production, for testing, experimental, unsupported, or obsolete. The logsource critical field specifies the source of the log data against which the rules will be run. Informational fields like status, author, license and description are optional but recommended.
Before writing a Sigma rule, think about what you are trying to accomplish. Is your goal, for example, to detect instances of a common string (payload) associated with a particular vulnerability exploit, or to monitor occurrences of a particular log event?
This is a basic Sigma rule:
title: Test Sigma rule
A real scenario rule would look more like the one shown below. The rule titled “Remove immutable file attribute” triggers the display of a log event generated by the Linux audit daemon (‘auditd’) whenever immutable file attributes are removed from a file. The selection criteria specified in the “detection” section is a set of key-value pairs. The rule, in this example, will only fire when the field type is EXECVE and the arguments (a0, a1) passed contain “chattr -i”:
The false positive field is not processed by the SIEM application but rather is an indicator for the SOC analyst to be aware of situations that may trigger false positives which may not require immediate correction. The condition field determines the conditions that must be met for the event to fire. In this case, it simply follows the selection criteria, but the condition field can allow for a more complex and detailed rule, as defenders can use logical operators such as AND/OR/NOT to combine different conditions.
For example, the rule below would only trigger when the “selection” criteria is met, but not what the “filter” specifies. The Sigma expression searches for event 4738: “A user account has been modified”. in Windows logs but only alerts when the PasswordLastSet field is not null.
Likewise, the selection criteria themselves can become detailed and complex and use value modifiers. An example of selection criteria using the “endswith” modifier is shown in the Intezer example below:
The rule will look for two fields ParentImage and Image and will only fire if the values of the fields ‘ParentImage’ AND ‘Image’ end with strings specified in the criteria. However, the values for each of them are specified in “list” format – and any of these values for ParentImage will trigger the rule. That is, the rule will fire when the image ends in mshta.exe AND ParentImage ends in svchost.exe OR cmd.exe OR powershell.exe.
Note that items specified under “list” or “card” objects have the “OR” operator applied to them, so detecting one of the specified selections in a list or card will trigger an alert.
Strings in Sigma are case insensitive by default but become case sensitive if they contain regular expressions (regex). Additionally, wildcards such as “*” and “?” are allowed in the detection criteria and can be escaped (using a “”) if necessary.
Common Sigma Rule Mistakes
Not knowing when rules are case sensitive
Because strings in Sigma rules are not case-sensitive except when they contain a regex pattern, advocates new to writing these rules may inadvertently introduce errors. A wrong rule can turn out to be a wasted effort and a lack of security because it may never be triggered when expected.
Incorrect use of the backslash
Another source of error comes from the improper use of the backslash when escaping strings, especially using the wrong number of backslashes. This is especially a problem in regular expressions.
The rules creation guide explains a solution to avoid this. Cases where only single backslashes are used by themselves do not need to be escaped. For example, the string C:WindowsSystem32cmd.exe does not need to be escaped and the single backslash will be treated as an “ordinary” string value. In other words, defenders should not escape single backslashes by writing “C:WindowsSystem32cmd.exe”.
A work Example this is shown in a Sigma rule shared by Florian Roth himself. The rule alerts system administrators when they see instances of the “ping” command receiving a hexadecimal-encoded IP address, possibly to avoid detection. Notice, the use of wildcards
and the “” not being escaped.
Backslashes can, however, be used as a means of escaping wildcards and a group of backslashes. For example, “*”, “and” and “?” are treated as wildcards, so it’s best for rule writers to write “*” if they literally want to include an asterisk rather than a wildcard operator. Also, the guide specifies: “If you want to express two single backslashes, use four: \foobar gives the value foobar…”, which means that writing gives you two backslashes in a string. “Write * if you want a single wildcard * as the result value. Write * if you want a single backslash followed by a wildcard * as the result value. Write * if you want a backslash simple inverse followed by a single * as the resulting value”, explain the instructions in more detail.
Logical errors due to operator misuse
When crafting the selection criteria and condition required to trigger the rule, pay attention to how your expression is evaluated. Creating an expression with multiple expressions using the OR operator when your logic is supposed to pass AND can trigger a plethora of false alarms. This can become particularly difficult to master when combining multiple selection criteria (containing a list of items) with the condition field combining those criteria using AND/OR/NOT.
Drafting and validation of your Sigma rules
Threat Hunting and Cyber Threat Intelligence Analyst Syed Hasan shared a step-by-step guide on how to write and compile your Sigma rules from scratch. Better yet, as Hasan suggests, why not use a web tool like Uncoder, especially as a beginner?
Published by SOC Prime, Uncoder lets you easily write, experiment, test and compile Sigma rules from the comfort of your web browser and even convert your rules to native SIEM languages.
As for validation and testing, the official Sigma repository provides a suite of tests that you can use to validate your rules. However, as cybersecurity engineer Ryan Plas rightly points out, some may find the sequel incomplete. The tests provided act as a useful resource but are by no means a complete means of verifying your compliance with the Sigma schema. Running the test suite requires defenders to manually download them and place them in their rules folder. Tools like sigmalint, developed by Stage 2 Security, can help with this. Sigmalint is an open source command line tool for validating your Sigma rules against the Sigma schema. “Using sigmalint is easy. You can pass two parameters: input directory and method. input directory
is the location of your rules directory and the method is the validation system you want to use (rx, jsonschema, s2),” Plas explained. “The script then generates a report showing the number of valid and invalid rules and the number it could not parse.” Since April of this year, contributed Sigma rules are undergoing automated checks
to ensure accuracy using event log data collected from uncompromised Windows systems.
Getting started with Sigma rules is fairly easy but, as with anything, it takes some practice to write them down to familiarize yourself with more sophisticated syntaxes and improve your detection capabilities.
Copyright © 2022 IDG Communications, Inc.