Tag: rules

A typical corporate network consists of hundreds or thousands of devices generating millions of lines of logs pouring in every minute. What can make it possible, then, for SOC and threat intel analysts to sift through all this flow of information efficiently and separate malicious activity from daily noise in an automated fashion?

This is where Sigma rules come in handy.

What are sigma rules?

Sigma rules are textual signatures written in YAML that make it possible to detect anomalies in your environment by monitoring log events that can be signs of suspicious activity and cyber threats. Developed by threat intel analysts Florian Roth and Thomas Patzke, Sigma is a generic signature format for use in SIEM systems. A prime advantage of using a standardized format like Sigma is that the rules are cross-platform and work across different security information and event management (SIEM) products. As such, defenders can use a “common language” to share detection rules with each other independent of their security arsenal. These Sigma rules can then be converted by SIEM products into their distinct, SIEM-specific language, while retaining the logic conveyed by the Sigma rule.

Whereas among analysts, YARA rules are more commonly associated with identifying and classifying malware samples (files) using indicators of compromise (IOCs), Sigma rules focus on detecting log events that match the criteria outlined by the rule. Incident response professionals, for example, can use Sigma rules to specify some detection criteria. Any log entries matching this rule will trigger an alarm.

The Sigma specification

The possibilities Sigma offers are vast and it therefore helps to familiarize yourself with the Sigma specification. It offers a long list of fields and defines what each means:

Sigma

Source: Sigma’s GitHub repository

From basic metadata fields such as the name and author of the rule to functional fields such as timeframe, string-identifier, and log source, Sigma rules allow for advanced monitoring of log events and entries.

How to write a Sigma rule

Every Sigma rule must have a title and an identifier. The title field briefly describes what the rule is supposed to do in no more than 256 characters. The id field is supposed 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 deprecated. The critical field logsource specifies the source of the log data that the rules will run against. Informative fields like status, author, license and description are optional but recommended.

Before writing a Sigma rule, think of what it is you’re 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, skeleton Sigma rule:

title: Test Sigma rule

id: 4d28fc3b-2ed7-4cd0-97c7-7a90b463c881
status: test

A real-life scenario rule would look more akin to the one shown below. The rule titled “Remove Immutable File Attribute” triggers seeing a log event generated by The Linux Audit Demon (‘auditd’) every time immutable file attributes are removed from a file. The selection criteria specified under the “detection” section is a set of key-value pairs. The rule, in this example, will trigger only when the field type is EXECVE and the arguments (a0, a1) passed contain “chattr -i”:

SANS

The falsepositives field isn’t processed by the SIEM application but is instead an indicator for the SOC analyst to be aware of situations that can trigger false positives that may require no immediate remediation. The condition field determines what conditions must be met for the event to trigger. In this case, it just 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 ‘selection’ criteria is met but not what the ‘filter’ specifies. The Sigma expression looks for Event 4738: “A user account was changed.” in the Windows logs but only alerts when the PasswordLastSet field is not null.

Similarly, the selection criteria itself can become detailed and complex and use value modifiers. An example of selection criteria using the “endswith” modifier is shown in the example from Intezer below:

Sigma

The rule will look for two fields ParentImage and Image and only trigger if both the values in the ‘ParentImage’ AND the ‘Image’ fields end with strings specified in the criteria. However, the values for each of these is specified in the “list” format – and any one of these values for ParentImage will trigger the rule. That is, the rule will trigger when the Image ends in mshta.exe AND ParentImage ends in svchost.exe OR cmd.exe OR powershell.exe.

Note, items specified under either “list” or “map” objects have the “OR” operator applied to them, so detection of any of the selections specified in a list or map will trigger an alert.

Strings in Sigma are case insensitive by default but become case sensitive should they contain regular expressions (regex). Additionally, wildcards like “*” and “?” are allowed in the detection criteria and can be escaped (using a “”) as needed.

Common Sigma rule mistakes

Not knowing when rules are case sensitive

Because strings in Sigma rules are case insensitive, except when they contain a regex pattern, defenders who are new to writing these rules might inadvertently introduce errors. An erroneous rule can turn out to be a wasted effort and a security miss as it may never be triggered when expected.

Improper backslash use

Another source of error comes from the improper use of the backslash when escaping strings, specifically using the wrong number of backslashes. This is particularly an issue in regular expressions.

The rule creation guide explains a solution to avoid this. Cases where only single backslashes are being used by themselves need not be escaped. For example, the string C:WindowsSystem32cmd.exe does not need to be escaped and the single backslash will be treated as a “plain” string value. In other words, defenders should not escape single backslashes by writing “C:\Windows\System32\cmd.exe.”

A working example of this is shown in a Sigma rule shared by Florian Roth himself. The rule alerts sysadmins on seeing instances of the “ping” command being provided a hex-encoded IP address, possibly to avoid detection. Notice, the use of wildcards (*) and the “” not being escaped.

Backslashes can, however, be used as a way of escaping wildcards and a group of backslashes. For example, “*”, “and” and “?” are treated as wildcard characters, so rule writers are better off writing “*” if they literally meant to include an asterisk as opposed to a wildcard operator.

Also, the guide specifies, “If you want to express two plain backslashes, use four of them: \\foobar results in the value \foobar…,” which means writing \\ gives you two backslashes in a string. “Write * if you want a plain wildcard * as resulting value. Write \* if you want a plain backslash followed by a wildcard * as resulting value. Write \* if you want a plain backslash followed by a plain * as resulting value,” further explain the instructions. 

Logical errors from operator misuse

When crafting selection criteria and condition that is required to trigger the rule, beware of how your expression is being evaluated. Crafting an expression with multiple expressions using the OR operator when your logic is meant to convey AND can trigger a plethora of false alerts. This can get especially difficult to master when combining multiple selection criteria (containing a list of items) with the condition field combining such criteria using AND/OR/NOT.

Writing and validating your Sigma rules

Threat hunting, and cyber-threat Intelligence analyst Syed Hasan has 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-based tool like Uncoder especially as a beginner?

Released by SOC Prime, Uncoder allows you to easily write, experiment with, test, and compile Sigma rules from the comfort of your web browser and even convert your rules into SIEM-native languages.

As for validation and testing, Sigma’s official repository provides a test suite that you can use to validate your rules. However, as cybersecurity engineer Ryan Plas rightfully points out, some may find the suite incomplete. The tests provided act as a helpful resource but are in no way a comprehensive means to check your compliance with the Sigma schema. Running the test suite requires defenders to download these manually 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: inputdir and method. inputdir is the directory location of your rules, and method is the validation system you want to use (rx, jsonschema, s2),” explained Plas. “The script then outputs a report of how many rules are valid and invalid and how many it couldn’t parse.”

As of April this year, contributed Sigma rules undergo automated checks to ensure their correctness using event log data collected from uncompromised Windows systems.

Getting started with Sigma rules is quite easy but, as with anything, it takes some practice writing them to get yourself familiarized with more sophisticated syntaxes and enhance your detection capabilities.