Write your first Sigma Rule

What is Sigma?

Sigma is an open-source language for writing detection rules. It describes what you want to find in logs, without caring about which security tool you are using.

Blue teams use Sigma to share detection logic. Someone writes a rule for detecting a specific attack, publishes it on Github, and thousands of SOC analysts can use it.

Why Sigma Matters

Normally, every SIEM has its own query language. Splunk uses SPL. Elastic uses KQL. Microsoft Sentinel uses Kusto. A detection rule written for Splunk can't run in Elastic.

Sigma fixes that.

The community maintains the SigmaHQ repository — a huge collection of rules for detecting everything. When a new attack technique appears, someone writes a Sigma rule for it within days.

The structure of a Sigma Rule

Every Sigma rule is a YAML file with specific fields.

title: Name of the rule
status: experimental
description: What this rule detects
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    ...
  condition: selection
level: medium

• title — what the rule detects
• status — how reliable it is (experimental, test, stable)
• description — a human-readable explanation
• logsource — what kind of logs this rule applies to
• detection — what patterns it's looking for
• condition — how to combine multiple patterns
• level — severity (informational, low, medium, high, critical)

Write a rule

Step 1: Detect brute-force attempts

Failed SSH logins look like this:

Jul  6 14:23:15 server sshd[1234]: Failed password for root from 45.67.89.10 port 22
Jul  6 14:23:16 server sshd[1234]: Failed password for root from 45.67.89.10 port 22
Jul  6 14:23:17 server sshd[1234]: Failed password for root from 45.67.89.10 port 22
Jul  6 14:23:18 server sshd[1234]: Failed password for root from 45.67.89.10 port 22
Jul  6 14:23:19 server sshd[1234]: Failed password for root from 45.67.89.10 port 22
Jul  6 14:23:20 server sshd[1234]: Failed password for root from 45.67.89.10 port 22

Multiple failed logins from the same IP very fast is most probably a brute-force attack. Let's write a Sigma rule to detect it:

title: SSH Brute Force Attack Detected
id: 2f6f9e1c-4b9a-4f5e-8d6f-3f0e2d0c1b1a
status: experimental
description: Detects multiple failed SSH login attempts from the same source IP within a short time period, indicating a possible brute-force attack.
author: CyberJournal
date: 2026/08/25
logsource:
  product: linux
  service: sshd
  category: authentication
detection:
  selection:
    type: 'FAILED'
    message|contains: 'Failed password'
  timeframe: 5m
  condition: selection | count() > 5
level: medium
tags:
  - attack.t1110
  - attack.bruteforce
  - attack.credential_access
falsepositives:
  - Legitimate users mistyping passwords repeatedly
  - Automated monitoring tools that use incorrect credentials

What Each Field Means

• title — human-readable name. Shown in alerts.
• id — a unique identifier (UUID).
• status: experimental — this rule is new and might generate false positives. After testing, you'd change it to stable.
• description — explains what the rule detects and when it should fire.
• logsource — Here we're saying: this rule applies to Linux authentication logs, specifically SSH.
• detection.selection — the actual pattern. We're looking for log entries where:
  • type is FAILED (failed login attempt)
  • message contains the text Failed password
• timeframe: 5m — look at a 5-minute window.
• condition: selection | count() > 5 — trigger when there are more than 5 matching events in 5 minutes.
• level: medium — severity. One failed login is nothing. Six in five minutes from the same IP is worth investigating.
• tags — maps to MITRE ATT&CK framework. T1110 is the technique ID for Brute Force. This is how analysts cross-reference Sigma rules with threat intelligence.
• falsepositives — documents when this rule might fire incorrectly.

Step 2: Understand the Detection Logic

Simple Match

detection:
  selection:
    EventID: 4625
  condition: selection

Triggers when EventID equals 4625 (failed Windows login).

Match Multiple Patterns (OR)

detection:
  selection1:
    EventID: 4625
  selection2:
    EventID: 4776
  condition: selection1 or selection2

Triggers on either event.

Combine Patterns (AND)

detection:
  selection:
    EventID: 4625
    IpAddress: '45.67.89.10'
  condition: selection

Triggers only when BOTH conditions are true — failed login AND from that specific IP.

Step 3: What Conversion Looks Like

Sigma rules aren't meant to run directly in your SIEM — they need to be converted into the SIEM's native query language. Tools like sigma-cli do this automatically. Here's what your brute-force rule would look like after conversion:

In Splunk (SPL):

index=linux sourcetype=sshd "Failed password" type="FAILED"
| stats count by src_ip
| where count > 5

In Elastic (KQL):

event.type: "FAILED" AND message: "Failed password"

Where to Find Real Sigma Rules

The SigmaHQ repository on GitHub has thousands of production-ready rules.

Browse by attack technique, platform, or product. Every rule is open source.

The MITRE ATT&CK framework is integrated throughout. Each rule has tags that map to specific attack techniques.