What are sigma rules?

Sigma rules are an open-sourced and generic language that allows you to create and share threat detection logic, which can then be used across multiple platforms to enable security analysts to detect threats better. The main goal of this standard is to give a structured form that security analysts can use to describe their detection methods and make them shareable with others.

Sigma was developed to enrich logs in the same way SNORT rules do for network traffic and YARA rules do for files, bridging a gap in open standards for log-based threat detection.

Why adopt Sigma rules for threat detection?

As businesses grow, it's inevitable that they undergo expansion rapidly to enter newer markets and capture new audiences. This means that they would have to scale up, which brings a whole lot of challenges, like moving into more complex infrastructure with multiple types of systems, networks, and devices.

With threats constantly evolving, organizations need to adapt their threat investigation strategies to stay ahead of cyberattacks. Sigma rules offer an efficient way to tackle this problem:

• You can write detection logic once and implement it across a vast variety of SIEM vendors by steering away from vendor lock-in and enabling a seamless experience in sharing detection rules.
• The YAML-based syntax of Sigma rules is human-readable and much easier to write. This format enables you to develop or modify detection rules more swiftly than ever.
• With Sigma, your organization can quickly gather and encode Indicators of Compromise (IoCs) and behavioral patterns and transform them into usable detection rules, helping you respond to emerging threats faster.
• As your environment or log sources change, Sigma rules can be adapted with minimal effort, only updating specific fields or modules as necessary. This saves your security team a lot of time dwelling on rewriting the detection rules, freeing them up to spend their effort on what actually matters.

Security professionals are adopting Sigma rules to streamline and strengthen their detection capabilities.

How do Sigma rules work?

Sigma rules work by defining detection logic and log source information in a standardized, human-readable YAML format. This format effectively captures all the important details about the logs, especially the anomalous behaviors within your network, making the rules flexible and easy to write.

To address the challenge that comes with diverse log schema and varying SIEM query languages, Sigma relies on converter tools called backends, which automatically translate the generic Sigma rule into a SIEM-compatible query. In the beginning, what started as a format for threat intelligence sharing, Sigma has evolved into a machine-readable standard that supports automated deployment and updates.

Backed by a large, active, open-source community contributing over 3,000 detection rules, Sigma enables collaborative, scalable, and platform-independent threat detection across any type of log source.

Basic components of a Sigma rule

Once a detection logic is written in Sigma, it will then be fed to a converter, which generates queries for specific platforms like Log360, Splunk, and Exabeam, among other vendors. You can then have it implemented easily in your SIEM to supercharge threat detection strategies. First off, you must define what your goal is before you go on to write a Sigma rule. It can vary depending upon an organization's need, ranging from just monitoring a specific log source or just an endpoint to putting pieces of IoCs together to reconstruct an exploit, for instance.

Regardless of whatever your goal is, a rule comprises certain mandatory fields and a few optional ones. With Sigma being a flexible format, you can navigate building these rules with freedom while making sure your logic is right and then adding further relevant data wherever it's possible.

Now let's explore the basic components that make up a sigma rule:

• Detection logic
• Log source
• Metadata

Detection logic: This component in a rule defines the conditions that need to be met for the rule to get triggered. This is the most integral section of any sigma rule, as it scours the anomalous behavior for which a rule is defined.

Let's look at a simple rule to understand the importance of the detection section:

This example tells the rule to detect any log entry where the event ID is 4625 and the logon type is 3. It represents a simple AND condition. However, you can also have multiple selections and have them combined with appropriate logical conditions to build a more complex rule to detect advanced threats.

Log source: This part of the rule is just as important as the detection logic, as it tells the rule to look for a described event only in a specific type of log source instead of searching over all the logs within your SIEM solution. Let's consider the same example as above to explain this element in a rule:

• Logsource: This section defines the type of log data that should be searched by the rule.
• Product: Indicates a specific platform or operating system like Windows or Linux. In this case, Windows means the rule is looking at Windows event logs.
• Service: This describes a service running within a product.
• Category: This element further refines the log source by specifying the type of event logs the rule actually targets.

This configuration tells the rule to look for failed logon events (EventID: 4625) with network logon type (LogonType: 3) specifically within Windows Security logs. With this rule, you are configuring the detection tools only to search and evaluate logs that come from the Windows security event source.

It further prevents the rule from generating false hits on unrelated logs (e.g., application logs, network device logs, or cloud logs) and ensures efficient detection.

Metadata: Any component of a rule other than the log source and detection logic is considered metadata. The purpose of metadata is to provide additional context about the detection for the users to help them understand and implement the rule better.

Here is a list of standard metadata fields that you should know about:

• Title: Provides a concise summary of what the objective of a rule is.
• ID: A unique identifier assigned to each rule that exists in the form of a universally unique identifier (UUID).
• Author: The details about the creator of a specific rule. This may be an individual, a handle, or an organization.
• Description: This describes the purpose for which a rule is created and how it detects an anomalous event.
• Date: The exact date data is created or modified.
• Status: This field lets users know if a rule is deployment-ready.
• Level: Indicates the criticality of an alert that is generated by the rule.
• References: This field provides URLs or any citations as to why or how the rule was developed in the first place.
• False positives: Specifies the list of possible false positives that may trigger the rule.
• Tags: Identifiers categorizing the rule by attack technique, tool, malware family, or campaign.
• License: Indicates how the Sigma rules can be used by others within the community.

This streamlined approach provides clarity in developing and managing the detection rules across any log source or SIEM platform efficiently.

Some of the common threats detected by Sigma rules

Let's explore in detail a few of the threats that you can detect with Sigma rules for a better understanding of how rules works.

Example one: Mitigating log4j-related vulnerabilities

This rule flags attempts to exploit the log4j RCE flaw. For log source, in this case, logs generated from web servers running Apache are only considered for evaluation.

The detection logic sets out to look for the presence of suspicious strings (${jndi:ldap://, ${jndi:rmi://, etc.), since these are the markers attackers use in Log4j exploits. The |contains| operator matches any log entry whose request field includes one of these patterns. Now, this rule can be transformed into a specific query that fits into any of the SIEM solutions that support Sigma rules.

Example two: Detecting suspicious activity in Amazon S3 buckets

This rule detects any suspicious S3 bucket changes. It considers only CloudTrail logs generated from AWS for evaluation.

s3.amazonaws.com limits the rule to only capture S3 service events. This rule triggers when one of the list of S3 API actions indicative of bucket ACL, policy, or other configuration changes that are suspicious occurs.

This rule can be transformed into queries for popular SIEM platforms using Sigma converters or backends, making it vendor-agnostic and easy to integrate into your detection workflows.

Best practices for implementing Sigma rules

There are numerous resources on the web that help you create Sigma rules to combat the growing number of ways adversaries can exploit your business's critical assets and data. It is essential to have all the rules that are developed undergo testing alongside other things to enable smoother implementation.

Here is a list of important practices you should adopt for a successful integration of Sigma rules with your SIEM solution:

• Carefully evaluate your infrastructure and decide what your business needs are. Consider the number of log sources and workflows you have already implemented in your network to inform this decision.
• As your network grows more complex and the threat landscape shifts, review and update the rules periodically to address all the possible threats that come with it.
• Provide meaningful metadata to help other consumers of a rule understand a rule’s intent, context, and use case.
• Ensure that alerts triggered by Sigma rules are integrated seamlessly into your incident response workflows and ticketing tools. It enables you to detect and respond to a security incident faster than ever.

These are some of the best practices you can adopt while implementing Sigma rules in a SIEM solution. Furthermore, regularly identify and address any potential gaps in the existing set of rules, thereby ensuring you are building an exhaustive strategy to fend off threats as they emerge.

How the integration of Sigma rules with Log360 enhances your threat detection capabilities

ManageEngine Log360 is a unified SIEM solution that detects, prioritizes, investigates, and remediates security incidents with its powerful features all delivered within a single console. It extends its footprint beyond just log management among other notable SIEM capabilities like advanced threat detection, user and entity behavior analytics, and more, by adopting a reengineered detection approach to empower SOC teams to overcome modern cybersecurity challenges.

With modern threats evolving, Log360 now takes it a step further by maintaining parity with over 2,000 MITRE ATT&CK®-based rules, all delivered via the cloud, to leave no stone unturned in your efforts to detect threats promptly and act on them. Our rule library undergoes frequent updates to integrate new, modified, and deprecated rules with every monthly release that Sigma brings to stay current with the evolving threat landscape.

Log360's unified security analytics dashboard provides a quick snapshot of all the security events happening in your infrastructure. Let's explore a few of the insights you can quickly draw from this high-level summary:

• Highlights how each of the detections align with MITRE ATT&CK tactics. This gives you comprehensive visibility into which stages of the attack are most prevalent in your network.
• Identifies users with the highest number of alerts. Insiders often carry out attacks in multiple stages through devices that are otherwise unrelated to them. Log360 helps you connect these events by piecing back such multiple incidents to remediate them faster.
• Achieve complete attack traceability with insights into a recent detection's critical details.

Log360 also brings advanced rule optimization techniques that help you confidently investigate and neutralize threats. Configure object-level filters across users, groups, and objects, and define rule exceptions to minimize false positives, ensuring focus on the most sensitive assets and accounts that truly matter.

Log360 also enables you to build detection logic at scale with its rule creation framework to hunt down more complex threats that loom in your network. The TDIR engine within the console now offers insights into false positive trends, the criticality of assets, and more.

Log360's integrations with threat intelligence feeds further bolster your investigation efforts by correlating Sigma-based alerts with threat intel and contextual IoCs gathered to spot threats precisely. With Log360's powerful incident management console at the helm, you can significantly reduce your MTTD and MTTR and improve the functioning of your SOCs by a great margin.

With Log360's powerful GenAI chatbot, Zia, you can now supercharge your SOC's toolkit by eliminating the need to piece together siloed data to determine the severity of threats with highly contextual insights, and respond to them with high precision and speed.