Security information and event management systems (SIEMs) have been a staple of the enterprise security toolset, giving organizations a way to aggregate data from across the environment. However, within the highly competitive SIEM market, organizations face challenges as the tools often use vendor-specific query languages, requiring security analysts to have specialized skill sets. Additionally, depending on the enterprise technology stack, many enterprise security teams find that they need to rewrite detection rules for other intrusion detection tools or across multiple SIEMs, complicating security further and adding to administrative costs.
For security teams looking to automate their detection capabilities, Sigma Rules provide a vendor-agnostic format to describe log events, enabling teams to future-proof their security workflows.
What are Sigma rules?
Detection engineer Florian Roth and open-source security technology developer Thomas Patzke introduced Sigma rules in 2017. Recognizing the challenge that security teams faced, the pair created Sigma as a generic, text-based, open signature format for creating detections, reducing the reliance on SIEM proprietary languages.
Sigma rules are stored in the YAML file format to allow for treating detections as code. The YAML files – which stands for Yet Another Markup Language – use a human-readable format to provide a shared language that defenders can use to detect threats in any environment. The main Sigma rule repository on GitHub provides three main types:
-
Generic Detection Rules: to detect a behavior, technique, or procedure
-
Threat Hunting Rules: to act as a starting point when looking for potential suspicious or malicious activity
-
Emerging Threat Rules: to cover specific timely and relevant threats for a defined time period, like zero-day vulnerabilities or specific malware variants
What are the benefits of Sigma rules?
The open-source standard enables security operations centers (SOCs) and threat hunting teams to collaborate more effectively with a comprehensive SIEM detection ecosystem that supports various platforms and use cases. With Sigma rules, enterprise security teams can write a detection once, which can in turn reduce the overall administrative costs. Further, Sigma rules reduce the skills barrier to entry with an easy-to-read format, enabling companies to focus more on security outcomes when hiring new team members instead of seeking only those who know a vendor-specific query language. Based on the detection as code approach, Sigma rules are typically stored in a code repository, such as GitHub. Using a code repository enables version control, allows rule changes to be reviewed and approved before moving into production and provides an easy mechanism for sharing within an enterprise or across the world.
With Sigma rules, defenders across the enterprise security team can:
-
Create standardized detection rules: Each Sigma rule contains the same fields, so a global enterprise with a multi-SIEM architecture or geographically diverse security teams can use a converter to translate the rules into the appropriate format.
-
Collaborate internally and externally: The open-source Sigma rule repository enables defenders to share knowledge, test rules, and bridge the cybersecurity skills gap by freeing them from the limits of proprietary detection formats.
-
Prevent vendor lock-in: Organizations can make their cybersecurity technology choices based on use cases and needs rather than integration with other tools.
What are the components of a Sigma rule?
Sigma rules have a flexible, easy to write, format that makes them applicable to any type of log file. The structure can be broken into three categories.
Detection
Since the format is flexible, the Sigma rules can become extremely complicated, which can confuse new users. However, at their core they adhere to some guiding principles:
-
Selections: define the detection to help organize for readability and filtering purposes
-
And/Or: use YAML Lists and Dictionaries to complete “AND” or “OR” operations
Using these guiding principles, Sigma detections follow three main patterns:
-
Keyword: Matching log source text with keywords related to the activity
-
Field Value: Representing fields as YAML “object” to match names and values, including where multiple fields appear together
-
Multiple Field Values (List): Providing a way to group multiple field values as a YAML list
Logsource
The logsource section helps identify the application for which a rule was written. This information allows Sigma engines (the code that matches rules to log data) to more efficiently evaluate the rules across the logs within a SIEM.
Sigma rules include three logsource fields:
-
Category: type of technology, like webserver, firewalls, or endpoint detection and response (EDR)
-
Product: specific product, like Windows, Linux
-
Service: service running within a product, like Kerberos or Windows Defender
Metadata
Additional data, known as rule metadata, can be added to describe the rule .
The standard Sigma metadata fields include:
-
Title: summary of the rule’s objective
-
ID: unique identifier
-
Status: current state, like in-development, in-testing, or ready for use
-
Description: Reason for rule, use case, and when it triggers
-
License: specifies how people can use the rule
-
Author: information to contact the authors
-
Date/Modified: rule creation or modification data
-
References: underlying research about the reason for the rule
-
Tags: categorizations for and mapping to security frameworks and available standards
-
False Positives: list of possible false positive results
-
Level: Criticality