Sigma Rule (Detection Logic)

A Sigma rule is ==a generic, open-source YAML format used in detection engineering to describe suspicious security events in a log-source-agnostic way==. It acts as a universal signature—like Snort for network traffic or YARA for files—allowing defenders to write a detection once and automatically translate it into SIEM queries like Splunk, Microsoft Sentinel, or Elastic.

Core Structure of a Sigma Rule

A standard Sigma rule is divided into several mandatory and optional key-value blocks in YAML:

1. Header (Metadata)

Provides context, administration, and tracking details for the rule.

• title: Short, human-readable name of the rule.
• id: Unique GUID/UUID used to track the rule over time.
• status: Maturity level (e.g., experimental, test, stable, deprecated).
• description: Detailed explanation of what behavior or adversary TTP the rule targets.
• author: Creator or contributor name.
• date / modified: Creation and update timestamps.
• references: Links to threat intelligence reports, blog posts, or analysis.
• tags: Categorization tags, commonly mapping to MITRE ATT&CK tactics and techniques (e.g., attack.execution, attack.t1059.001).
• level: Severity rating (e.g., low, medium, high, critical).
• falsepositives: Known benign activities or administrative tools that might trigger false alerts.

2. Log Source (logsource)

Tells the translation backend which logs or platforms the rule applies to.

• category: High-level log type (e.g., process_creation, network_connection, file_event).
• product: Operating system or application (e.g., windows, linux, aws).
• service: Specific service or channel (e.g., security, sysmon, dns).

3. Detection Block (detection)

The core logic defining what patterns, strings, or field values to look for. It consists of individual search statements (selections or filters) combined via a boolean condition.

• Selections (Lists / Dictionaries):
  • Lists (YAML arrays [ ]) represent OR logic (matching any item in the list).
  • Dictionaries/Maps represent AND logic (matching all key-value pairs simultaneously).
• Modifiers: Appended to field names using a pipe (|) to alter string matching behavior:
  • contains: Matches substring anywhere in the field.
  • startswith / endswith: Anchors the match to the start or end of the string.
  • all: Changes a list from OR to strict AND.
  • re: Passes the pattern to a regular expression engine. [11]
• Condition (condition): Boolean statement that connects selections and filters (e.g., selection and not filter).

4. Output Fields (fields)

• Specifies which log attributes should be extracted and displayed when an alert triggers (e.g., CommandLine, ParentImage, User).

Example Sigma Rule Skeleton

title: Suspicious PowerShell Download Cradle
id: 12345678-1234-1234-1234-1234567890ab
status: experimental
description: Detects PowerShell executing a download command from a remote URL
author: Detection Engineer
date: 2026/10/27
tags:
  - attack.execution
  - attack.t1059.001
level: high
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - 'DownloadString'
      - 'IEX '
  filter:
    ParentImage|endswith: '\sccm.exe'
  condition: selection and not filter
fields:
  - CommandLine
  - ParentImage
  - User

---

The logsource section in a Sigma rule ==defines where and what kind of logs the detection logic should look through==. It acts as a filter so that conversion tools (backends) know which tables, indexes, or log types in your SIEM (like Splunk, Microsoft Sentinel, or Elastic) to target.

The Three Main Fields

The logsource section uses a combination of three primary attributes:

• product: Selects the overall software, operating system, or platform family generating the logs (e.g., windows, apache, aws, linux).
• category: Selects a standardized, high-level functional type or event class across different products (e.g., process_creation, file_event, firewall, dns).
• service: Narrows down the logs to a specific sub-service, daemon, or log channel within that product (e.g., sysmon, sshd, security, application).

How They Work Together (from Broad to Specific)

You do not always have to fill out all three fields. You combine them depending on how specific the rule needs to be:

1. Broad / Generic Category Only:
   

   logsource:
     category: process_creation
   

- _Meaning:_ Look for process creation events anywhere it is supported, regardless of the underlying product or OS.

1. Product + Category:
   

   logsource:
     product: windows
     category: process_creation
   

- _Meaning:_ Look for process creation events specifically coming from Windows systems. [4]

1. Product + Service + Category (Most Specific):
   

   logsource:
     product: windows
     service: sysmon
     category: process_creation
   

- Meaning: Specifically target Windows logs generated by the Sysmon service under the process_creation category (Event ID 1).

Why the Logsource Section Matters

• Portability: When you convert a Sigma rule using a translator tool (like sigmac or pySigma), the backend uses logsource to map generic field names (like Image or CommandLine) to the exact schema of your specific SIEM.
• Efficiency: It prevents your SIEM from running heavy search queries across irrelevant datasets or indexes.
• Standardization: It ensures that whether you write a rule for Linux, Windows, or cloud providers, the target telemetry is clearly labeled and expected.

---

The detection block in a Sigma rule is ==the core logic section that tells your security system what specific evidence or patterns to look for in log data==.

It acts as the "search brain" of the rule and is broken down into three main parts: selections, filters, and a condition.

1. Selections (What to Find)

• What it is: A list of field-and-value pairs or keywords that represent suspicious or specific behavior.
• How it works: You pick log fields (like EventID, Image, or CommandLine) and define what values trigger a match.

• Example:
  

  detection:
    selection:
      EventID: 4625
      TargetUserName: "admin"
  

  (This selection looks for a Windows event ID 4625—a failed logon—targeting the username "admin".) [1, 4, 5, 6, 7]

2. Filters (What to Ignore)

• What it is: Optional criteria used to exclude normal or safe activity (false positives).
• How it works: If a log matches your selection but also matches your filter, it gets dropped so it doesn't trigger a fake alert.

• Example:
  

    filter:
      SourceIpAddress: "192.168.1.100" # Ignore internal scanner
  

3. Condition (the Boolean Glue)

• What it is: A statement that connects your selections and filters using logic like AND, OR, NOT, or parentheses.
• How it works: It tells the engine how to evaluate the matches.

• Example:
  

    condition: selection and not filter
  

  (This triggers an alert only if the selection happens, and the filter does not.)

Simple Analogy

Think of the detection block like setting a security camera rule:

• Selection: "Record if anyone wears a ski mask and carries a crowbar."
• Filter: "Except if it's Bob from the maintenance crew."
• Condition: "If Selection A is true, and Filter B is false -> Sound the alarm."

If you'd like, share a sample Sigma rule or scenario you are working on, and I can help you break down or write its detection block.

---

In Sigma rules, ==selection defines the specific malicious or suspicious indicators you want to find, while filter removes known false positives or expected benign activity==.

1. Selection

The selection is the core matching logic of a Sigma rule. It tells the SIEM what fields and values to search for in log data.

• What it does: Captures suspicious attributes (e.g., a specific command-line argument, a unique registry key, or a rare process name).
• Structure: Written as YAML dictionaries (representing logical AND statements) or YAML lists (representing logical OR statements).

• Example:
  

  detection:
    selection:
      Image|endswith: '\powershell.exe'
      CommandLine|contains: 'EncodedCommand'
    condition: selection
  

  • Meaning: Match any event where the Image ends with powershell.exe AND the CommandLine contains EncodedCommand.

2. Filter

The filter (often named filter1, filter_..., or handled via standalone Sigma Filters) narrows down the results by excluding normal, authorized, or repetitive administrative behavior.

• What it does: Subtracts or ignores benign events that would otherwise trigger a false positive.
• Logic integration: Combined with selections using boolean operators like NOT or and not in the condition line.

• Example:
  

  detection:
    selection:
      Image|endswith: '\powershell.exe'
      CommandLine|contains: 'EncodedCommand'
    filter:
      User: 'NT AUTHORITY\SYSTEM'
    condition: selection and not filter
  

  • Meaning: Find all encoded PowerShell commands, except when run by NT AUTHORITY\SYSTEM (assuming that service account runs safe scripts in your environment).

How They Work Together

1. Match: The selection grabs a broad or specific bucket of potentially bad events.
2. Prune: The filter sweeps through that bucket and throws out known-good noise.
3. Condition: The condition statement ties them together (e.g., selection and not filter) to produce the final alert.

(Note: You can also use separate, modular Sigma Filters in modern pySigma workflows to manage environment-wide exclusions externally without editing the base detection rule).

---

Here is exactly what happens for each condition, using the security camera analogy (Selection = Someone in a ski mask, Filter = It is Bob the maintenance worker):

1. condition: selection and not filter

• What it means: Trigger an alert only for malicious activity.
• What happens: The activity you are looking for must happen (selection), AND it must not be the safe/excluded activity (not filter).
• Analogy: "Sound the alarm if someone in a ski mask shows up, and it is not Bob."
• Outcome: You catch the real bad guy. Bob can walk by in his ski mask freely.

1. condition: selection or not filter

• What it means: Trigger an alert for almost everything (A dangerous rule).
• What happens: The alert fires if the malicious activity happens OR if anything else happens that doesn't match the filter. Because the "not filter" side is true for 99.9% of all normal network traffic, this rule will completely flood your system with fake alerts.
• Analogy: "Sound the alarm if someone is in a ski mask, or if the person is not Bob."
• Outcome: The alarm goes off constantly for every single employee, customer, and delivery person who is not Bob, regardless of what they are wearing.

1. condition: selection and filter

• What it means: Trigger an alert only when your exception happens.
• What happens: The alert fires only when the activity matches the suspicious criteria AND simultaneously matches the exclusion criteria.
• Analogy: "Sound the alarm if someone is in a ski mask, and that person is Bob."
• Outcome: You are specifically spying on Bob. You will only get an alert when Bob wears a ski mask, while an actual criminal in a ski mask will walk right past the camera undetected.

1. condition: selection or filter

• What it means: Trigger an alert for either behavior.
• What happens: The alert fires if the malicious activity happens, OR if the safe/excluded activity happens.
• Analogy: "Sound the alarm if someone is in a ski mask, or if Bob walks by (even in his normal uniform)."
• Outcome: You catch the bad guy, but you also generate an annoying alert every single time Bob does his normal daily job.

---