SIGMA RULES
LATEST POSTINFOSEC BASICS
SIGMA Rules: An Overview
SIGMA is a generic and open signature format designed for writing detection rules for SIEM (Security Information and Event Management) systems. Much like how YARA is used to detect malware based on file patterns, SIGMA is used to detect malicious activities and attack techniques based on log events. The idea behind SIGMA is to provide a universal format for rules that can be converted to specific SIEM query languages (like Splunk, Elastic, or QRadar).
Key Components of SIGMA Rules
1. Title: A humanreadable name for the rule, describing what it detects.
2. Log Source: Specifies the type of log source (e.g., Windows event logs, Sysmon logs, firewall logs, etc.).
3. Detection: The core section where conditions and patterns to detect specific behavior are defined.
4. Condition: Defines when the detection should trigger based on logical conditions (similar to YARA).
5. Tags: Provides information on the context, such as specific MITRE ATT&CK tactics and techniques, malware family names, etc.
Basic Structure of a SIGMA Rule
Here's a template for a simple SIGMA rule:
```yaml
title: Suspicious Process Execution
id: b35e12b574524d61b3fff278a1c07c72
status: experimental
description: Detects processes spawned with suspicious parentchild relationships
author: Security Analyst
date: 2023/09/21
references:
https://attack.mitre.org/techniques/T1059/
logsource:
product: windows
service: sysmon
category: process_creation
detection:
selection:
ParentImage: 'C:\\Windows\\System32\\cmd.exe'
Image: 'C:\\Windows\\System32\\powershell.exe'
condition: selection
falsepositives:
legitimate administrative activities
level: high
tags:
attack.execution
attack.t1059.001
```
Explanation of Each Section
1. Title: Describes what the rule detects. This is a brief description, such as "Suspicious Process Execution."
2. ID: Each rule has a unique identifier (UUID) to track and reference it.
3. Status: Defines whether the rule is in an experimental, stable, or deprecated state.
4. Description: Provides a detailed explanation of what the rule is designed to detect.
5. Author: The name or alias of the rule creator.
6. Date: When the rule was created or last modified.
7. References: Provides links or documentation to support the detection logic. This often includes links to MITRE ATT&CK, threat reports, or malware analysis.
8. Log Source: Specifies the type of logs the rule will be applied to. This includes:
Product: The log source system (e.g., Windows, Linux).
Service: The specific logging service (e.g., Sysmon, Windows Event Logs, firewall).
Category: Type of activity (e.g., process_creation, network_connection).
9. Detection: This is the core section where the conditions for detecting suspicious behavior are defined.
Selection: Specifies the field values or patterns to match.
For instance, this rule looks for processes where `cmd.exe` is spawning `powershell.exe`, a potentially suspicious behavior.
Condition: Defines how to trigger the detection. This can include:
selection: A simple match condition.
count(): For thresholdbased detection.
not selection: For excluding certain patterns.
10. False Positives: Lists situations where the detection might trigger legitimate activity. For instance, administrative activities might legitimately spawn `cmd.exe` and `powershell.exe`.
11. Level: Indicates the severity or priority of the detection (e.g., low, medium, high).
12. Tags: SIGMA supports tagging the rule with specific MITRE ATT&CK techniques, tactics, or malware families. This rule is tagged with `T1059.001`, which corresponds to PowerShell execution.
Key Components of Detection Logic
In the detection section, you define how to detect specific activities or behaviors using the following constructs:
1. Field Matching: You match specific fields in the log data.
```yaml
selection:
EventID: 4624
LogonType: 2
```
2. Logical Conditions: SIGMA supports simple conditions like `and`, `or`, `not`.
```yaml
condition: selection1 and selection2
```
3. Multiple Selections: Sometimes, multiple selections are required, such as combining different conditions.
```yaml
detection:
selection1:
EventID: 4625
AccountName: 'admin'
selection2:
LogonType: 7
condition: selection1 or selection2
```
4. CountBased Conditions: You can count how many times an event occurs to detect thresholds.
```yaml
condition: selection | count() > 5
```
5. Time Windows: You can define timebased conditions. For example, detect if something happens a certain number of times within a specific period.
```yaml
condition: selection | count() by src_ip > 10 within 5m
```
Practical Example: Detecting Brute Force Logins
Here’s a SIGMA rule that detects brute force login attempts in Windows based on failed login events:
```yaml
title: Brute Force Login Detection
id: c19e274d21e24f3eb3b95a20f530ac30
status: stable
description: Detects brute force login attempts by counting multiple failed login attempts within a short time
author: Security Analyst
date: 2023/09/21
references:
https://attack.mitre.org/techniques/T1110/
logsource:
product: windows
service: security
category: logon
detection:
selection:
EventID: 4625
condition: selection | count() > 10 within 5m
falsepositives:
legitimate logon failures from administrators
level: medium
tags:
attack.credential_access
attack.t1110
```
Explanation:
Log Source: This rule focuses on Windows Security logs (`product: windows`) and looks at logon events (`category: logon`).
Detection: It looks for EventID `4625`, which indicates failed logon attempts, and triggers if more than 10 failed attempts occur within a 5minute window.
False Positives: Admins or users mistyping passwords could trigger this rule, so you may need to adjust for legitimate activity.
Level: Set to `medium`, as brute force attempts can indicate a potential attack, but might also trigger false positives.
SIGMA and MITRE ATT&CK
SIGMA rules are often tagged with MITRE ATT&CK techniques. For example, if a SIGMA rule detects the use of PowerShell for malicious purposes, it would be tagged with `T1059.001` (Command and Scripting Interpreter: PowerShell). This mapping helps security teams understand the tactics and techniques being used by attackers and align their detection strategies accordingly.
SIGMA Rule Deployment and Conversion
SIGMA rules are written in YAML, but most SIEMs use their own query languages. For example:
Splunk uses SPL (Search Processing Language).
Elastic uses Elasticsearch queries.
QRadar uses AQL (Advanced Query Language).
To bridge this gap, there are tools that convert SIGMA rules into the specific SIEM query language, making it easy to deploy the same rule across multiple platforms. The main tool for this is sigmacli, which converts SIGMA rules into SIEMspecific formats.
Example Conversion:
For Splunk:
```yaml
detection:
condition: selection
```
would be converted into:
```splunk
(EventID=4625)
```
For Elasticsearch:
```yaml
detection:
condition: selection
```
would be converted into:
```elasticsearch
{"query": {"bool": {"must": [{"match": {"EventID": 4625}}]}}}
```
Common Use Cases for SIGMA
1. Detecting MITRE ATT&CK Techniques: Many SIGMA rules are premapped to MITRE techniques, making it easier to detect common attack patterns.
2. Threat Hunting: Use SIGMA to automate the identification of known threat actor behaviors based on specific log events.
3. Incident Response: SIGMA rules can be used during incident response to identify suspicious or malicious activities across logs.
4. Compliance: Detecting specific actions like file deletions, access to sensitive resources, or unauthorized changes for auditing purposes.
Conclusion
SIGMA is a versatile, opensource tool that standardizes the way we write and share detection rules across SIEMs. With SIGMA rules, security professionals can write detections in a platformagnostic way and convert them to the specific query language of their SIEM. It's an excellent choice for threat detection, threat hunting, and incident response, especially when combined with frameworks like MITRE ATT&CK for mapping adversary tactics and techniques.