SIGMA Rules: how to standardize detections for any SIEM

SIGMA rules are a great collaborative tool for SOC teams. They allow to standardize the detection rules regardless of the SIEM in place.

At Yogosha, we believe in collaborative approaches for better cybersecurity. Threats and attacker profiles are spreading too fast for each organization to defend itself alone.

Effective security requires the aggregation of skills and resources.

That’s the general theory. The one behind bug bounty for example, but also behind SIGMA rules. They address this issue from a very specific angle: standardizing threat detection – and making the job of SOCs around the world much easier.

What are SIGMA rules?

SIGMA rules are a common language for threat detection that standardizes the detection rules regardless of the SIEM or system in use. Among other things, SIGMA rules allow:

• the creation and sharing of standardized detection rules that can be used by everyone;
• easy migration of rules when moving to another SIEM (Security Information Management System);
• the unification of log analysis for players who use several systems (SIEM, EDR, XDR…) such as MSSPs;
• the monetization of detection content by security researchers and ethical hackers, who can convert the fruits of their labor into marketable SIGMA rules.

Why use SIGMA rules?

SIGMA rules are to logs what YARA rules are to malicious files, or SNORT rules to network traffic. They simplify and streamline the daily tasks of SOC (Security Operation Center) teams.

SIGMA rules to standardize detections

With SIGMA rules, all SOC teams around the world can now exchange and apply detection rules regardless of the SIEM or system used. Not being tied to one technology or vendor allows for unparalleled flexibility and speed in threat detection.

Say you’ve created a Splunk rule to detect a new threat. Make it a SIGMA rule, and share it with peers who use QRadar, Qualys or other. The same goes for access to web resources, file modification or detection of any suspicious or unauthorized action.

That’s the beauty of SIGMA rules, all detections can be standardized, from the simplest to the most complicated, from the oldest to the most up-to-date.

SIGMA rules to verify data integrity

In addition to active threat detection, SIGMA rules can be used to analyze logs retrospectively – if they are retained, of course. Applying a SIGMA rule to older logs allows one to quickly look for a specific suspicious activity, in order to determine if there was a breach.

SIGMA Rules: where to start?

Good news: SIGMA rules are not complicated to use. They are written in YAML, and once you understand the logic and the main pitfalls to avoid, it’s a breeze.

The SIGMA Github

Here is the Github repository of SIGMA. You will find the project, as well as Sigmac, the rule compiler that allows to translate them according to the target SIEM. Note that the undercode.io tool allows to do the same thing online.

The Github is also a good starting point for learning, through the Wiki or by trying the many detection rules made available by the community.

How to write a SIGMA rule?

There are many resources on the web to help create SIGMA rules. Rather than repeat what has already been said, we refer you instead to: 

• How to write SIGMA rules, a tutorial written by Florian Roth, who is none other than the co-creator of the SIGMA project (the other one being Thomas Patzke);
• Defender’s Toolkit 102: Sigma Rules, another comprehensive how-to guide.

Here, we will simply go over the basics in order to understand how SIGMA rules work.

To operate, a SIGMA rule must specify:

• a data source – a log source;
• a detection factor: what to look for in the targeted logs;
• a target: the SIEM or the system that will analyze the logs – Splunk, Sysmon, Sumo Logic…

To do this, the SIGMA rules all follow the same structure, with various fields to fill in:

title:
id:
status:
description:
author:
references:
logsource:
   category:
   product:
   service:
   definition:
detection: 
   condition: 
fields: 
falsepositives:
level: 
tags:

Only the logsource and detection sections are really necessary. The others are metadata that ease the understanding and adoption of the rule by the rest of the community. The Log Source section is essential because it specifies the logs that must be analyzed. The Detection part is the heart of the SIGMA rule, since it is here that we will indicate what to look for in the logs.

Example: a SIGMA rule to detect an RCE exploit in Oracle WebLogic

Since there’s nothing like demonstrations, let’s have an example. The following SIGMA rule, available on Github, allows the detection of the exploitation of the RCE vulnerability in Oracle WebLogic Server described in CVE-2021-2109. It is written in YAML as follows:

title: Oracle WebLogic Exploit CVE-2021-2109
id: 687f6504-7f44-4549-91fc-f07bab065821
status: test
description: Detects the exploitation of the WebLogic server vulnerability described in CVE-2021-2109
references:
    - https://twitter.com/pyn3rd/status/1351696768065409026
    - https://mp.weixin.qq.com/s/wX9TMXl1KVWwB_k6EZOklw
author: Bhabesh Raj
date: 2021/01/20
modified: 2022/10/09
tags:
    - attack.t1190
    - attack.initial_access
    - cve.2021.2109
logsource:
    category: webserver
detection:
    selection:
        cs-method: 'GET'
        c-uri|contains|all:
            - 'com.bea.console.handles.JndiBindingHandle'
            - 'ldap://'
            - 'AdminServer'
    condition: selection
fields:
    - c-ip
    - c-dns
falsepositives:
    - Unknown
level: critical

Now, here is the same rule translated in a query for QRadar:

SELECT UTF8(payload), "sourceip" FROM events WHERE UTF8(payload) ILIKE '%GET%' AND "URL" ILIKE '%com.bea.console.handles.JndiBindingHandle%' AND "URL" ILIKE '%ldap://%' AND "URL" ILIKE '%AdminServer%'

And here with Splunk:

index=* (cs-method="GET" AND c-uri="*com.bea.console.handles.JndiBindingHandle*" AND c-uri="*ldap://*" AND c-uri="*AdminServer*") | table c-ip,c-dns

Or here with Graylog:

(cs-method:"GET" AND c-uri:*com.bea.console.handles.JndiBindingHandle* AND c-uri:*ldap\:\/\/* AND c-uri:*AdminServer*)

Useful, isn’t it?

What SIEMs and systems are supported by SIGMA Rules?

To date, 25 SIEMS (and derivatives) are supported by SIGMA rules, as listed on Github:

• Splunk
• ElasticSearch Query Strings
• ElasticSearch Query DSL
• Kibana
• Elastic X-Pack Watcher
• Logpoint
• Microsoft Defender Advanced Threat Protection (MDATP)
• Azure Sentinel / Azure Log Analytics
• Sumologic
• ArcSight
• QRadar
• Qualys
• RSA NetWitness
• PowerShell
• Grep
• LimaCharlie
• ee-outliers
• Structured Threat Information Expression (STIX)
• LOGIQ
• uberAgent ESA
• Devo
• LogRhythm
• Datadog Logs
• FortiSIEM
• HAWK.io MDR

Crowdsourced security to strengthen global security

SIGMA rules are a great tool of collaborative security. By standardizing detection rules, they facilitate the exchange of detection strategies between different security professionals – SOC analysts, CISOs, ethical hackers…

In other words, SIGMA rules promote better overall security by allowing collective intelligence to be freed from secondary considerations such as the choice of SIEM or the system to be used. This is an initiative that we at Yogosha can only welcome, since it is precisely the philosophy behind the Vulnerability Operations Center (VOC).

The VOC is to offensive security what the SOC is to defensive security. Like SIGMA rules, the VOC improves vulnerability detection by promoting collaboration between security communities and reducing friction between tools.

Read also: What is a Vulnerability Operations Center (VOC)?