In cybersecurity as in sports, teamwork makes the dream work. In a world where security analysts can feel constantly bombarded by threat actors, banding together to share information and strategies is increasingly important. Over the last few years, security operations center (SOC) analysts started sharing open source Sigma rules to create and share detections that help them level the playing field.

By understanding what Sigma rules are and how to use them, you can leverage their capabilities, optimizing your centralized log management solution for security detection and response.

What are Sigma Rules?

Introduced in 2017 by detection engineer Florian Roth and open-source security tool developer Thomas Patzke, Sigma is a text-based, generic, open signature format that analysts can use to describe log events, making detections easier to write.  Since Sigma uses YAML, it has a human-readable syntax that means people can easily read and understand the detection rules.

As a generic detection rule format, Sigma creates a common shared language for defenders, overcoming the challenges that they face trying to write rules in proprietary Security Information and Event Management (SIEM) platforms. Security analysts can share rules using the Sigma format, then convert them into the SIEM-specific language.

Similar to how YARA rules use Indicators of Compromise (IoC) to help identify and classify malware files, Sigma rules match criteria to log events to help detect incidents. Sigma rules can contain any or all of the following fields:

• Title
• Status, like experimental or tested
• Description of what it detects
• Author name
• Date
• ID
• License, assuming the author shares the rule
• Level
• Data or log source
• Set of conditions
• Tag, including MITRE ATT&CK mapping

Why use Sigma Rules?

With Sigma rules, security analysts can collaborate more effectively and efficiently.

Standardization

Sigma standardizes detection rule formats across all SIEM and log management platforms. Since each rule contains the same fields in the same order, security analysts can use a converter that translates the open-source detection into the format that their security system uses.

Collaboration

For defenders, collaboration is a fundamental benefit. Until Sigma rules, security analysts could only share detections with other people who use the same SIEM or log management system. With open-source Sigma rules, defenders can share tested and untested rules within GitHub to build stronger detections.

Further, by collaborating, defenders can share knowledge. With people across all experience levels sharing detections, security analysts can bridge the cybersecurity skills gap, enhancing everyone’s security.

Flexibility

From a business perspective, Sigma rules give companies a way to evolve their cybersecurity technology stack in a way that makes sense for them. The ability to convert the rules to a vendor’s format means that security teams can shift from one technology to another more easily, avoiding costly vendor lock-in or enabling them to mature their operations as necessary.

Sigma Rule Use Cases

With Sigma, you can uplevel your security in proactive and reactive ways.

Suspicious Activity Alerts

To improve your reactive security, you can build Sigma rules to detect suspicious activity. Using the activity that your log data captures, you can build rules that detect almost anything, including:

• Unauthorized actions
• Web/resource access
• File modification
• Process creation

As you get more comfortable building detection rules, you can correlate more log data for meaningful, high-fidelity alerts.

Threat Hunting

Once you have a set of robust alerts, you can start using Sigma rules to mature your proactive security monitoring, too. With a centralized log management solution aggregating old log data, you can build Sigma detections based on threat intelligence and proactively search for activity indicating attackers hiding in your systems.

The Anatomy of a Sigma Rule

Writing Sigma rules doesn’t need to be hard, but the more correlations you build into the rule, the more difficult writing it becomes.

An example of a short Sigma rule is the one that identifies potential brute force or credential theft attacks.

Identify Use Case

The first step to building a Sigma rule is deciding what activity you need to find.

In the example detection, the authors define the use case in the tags as an attack at the credential and access level.

They also map this activity to the MITRE ATT&CK Technique T1110 which covers:

• Password guessing (T1110.001)
• Password cracking (T1110.002)
• Password spraying (T1110.003)
• Credential stuffing (T1110.004)

Determine Log Source/Data Source

Since your Sigma rule relies on log data, you need to identify what sources apply. When writing the rule, you may want to include both the product and the service.

Breaking down the example detection, you can see that the logsource in this case is the Azure sign-in logs:

Define the Detection

As you continue to build your rule, you also dig deeper into the logsource data. When you define the detection, you look at the log fields that alert you to specific activity.

In this example, the sign-in logs for “Azure AD authentication error 50053”:

Set the Condition

When you set the condition, you define what the rule “looks for” in the defined log.

In this case, since the log needs to have the required error, you set it as follows:

Additional Fields and Complexity

Although valuable, this example is a fairly simple rule. As you try to reduce noise across your monitoring environment, you may incorporate additional information, like:

• More than one log source
• More than one detection
• Filters
• Multiple conditions
• Indicators of false positives

A good example of a more complex Sigma rule is the Sign-In Failure for Bad Password Threshold:

Graylog Security: Sigma Rule Event Processor for Advanced Detection Capabilities

With Graylog Security, you get the security functionality of SIEM and the intuitive user interface that makes managing security faster. With our Sigma Rule Event Processor, you can import rules you want to use directly from GitHub, and we automatically associate it with an event definition or customize the definition, giving you a way to rapidly mature your detection capabilities.

By combining Sigma rules with Graylog’s lightning-fast speed, you can create the high-fidelity alerts you need and investigate them rapidly, improving key metrics like Mean Time To Detect (MTTD) and Mean Time To Resolve (MTTR).