Rules

Top-level fields

A valid rule must define top-level identifiers, a detection block, a logsource, and a metadata section, and can optionally add MITRE ATT&CK and compliance mappings.

The following table lists all supported top-level fields in a Wazuh Sigma rule. Fields marked as required must be present for the rule to pass validation.

Wazuh rule sample

The following example demonstrates a complete Wazuh detection rule using all supported blocks:

metadata:
  title: Python SQL Exceptions
  author: Thomas Patzke
  description: Detects SQL exceptions in Python applications according to PEP 249.
id: 9c1c1e3f-21ad-4db0-9bb4-5cf2e9c1b901
sigma_id: 19aefed0-ffd4-47dc-a7fc-f8b1425e84f9
status: stable
level: medium
enabled: true
tags:
  - attack.initial-access
  - attack.t1190
logsource:
  category: application
  product: python
detection:
  keywords:
    - DataError
    - IntegrityError
    - ProgrammingError
    - OperationalError
  condition: keywords
falsepositives:
  - Application bugs
mitre:
  tactic:
    - TA0001
  technique:
    - T1190
  subtechnique: []
compliance:
  pci_dss:
    - "6.5.1"
  gdpr:
    - Art. 32

Components of Wazuh rules

A Wazuh Sigma rule is composed of the following blocks:

Required

• Detection

• Log source

• Metadata

Optional

• MITRE ATT&CK

• Compliance

Detection

The detection block defines when a rule matches an event. It tells the detection engine what to look for in an event and how to combine those checks into a final match decision. It consists of one or more named selections (or keywords) and a condition that combines them using Boolean logic.

Every detection block has two required parts:

• Condition: A condition field wires the selections together using Boolean logic (and, or, not) to produce a true/false result for each incoming event.

• Selection: One or more named selections (or a keyword list) that define the conditions to check.

Example:

detection:
  condition: selection
  selection:
    event.action: account-locked
    event.category|contains: authentication

detection:
  selection:
    event.action:
      - login_failed # or
      - authentication_error
  condition: selection

detection:
  selection:
    log.level: ERROR # and
    event.kind: event
  condition: selection

detection:
  keywords:
    - DataError # or
    - IntegrityError
    - OperationalError
  condition: keywords

condition: (selection_one or selection_two) and not filter

detection:
  sel_severity:
    event.severity|gte: 8
  sel_message:
    message|contains: fatal
  condition: sel_severity and sel_message

detection:
  sel_error:
    log.level: ERROR
  sel_warn:
    log.level: WARN
  condition: sel_error or sel_warn

detection:
  selection:
    event.kind: event
  filter:
    process.thread.name|startswith: Test
  condition: selection and not filter

detection:
  sel_high:
    event.severity|gte: 8
  sel_critical:
    log.level: CRITICAL
  filter:
    process.name: monitor
  condition: (sel_high or sel_critical) and not filter

field_name|modifier: value

event.category|contains|all:
  - authentication
  - failure

Log source

The logsource block specifies the type of log data the rule applies to. It tells Wazuh which integration owns the rule and helps organize rules by platform, log type, and service, making it easier to find, filter, and audit your rule library.

The logsource block does not directly affect detection matching. The detection block determines whether an event triggers the rule. logsource is metadata that ties the rule to an integration and organizes it within the Content Manager.

logsource:
  product: linux
  category: authentication
  service: sshd
  definition: Ensure sshd authentication logs are collected via the Wazuh Linux integration.

The logsource block has one required field and three optional fields. product is required; every rule must declare the platform or integration it targets. The category, service, and definition fields are optional and can be added to narrow scope, improve grouping, or document prerequisites, but the rule will validate without them.

logsource:
  product: linux

logsource:
  category: authentication

logsource:
  service: sshd

logsource:
  definition: Script Block Logging must be enabled

See Sigma Log Sources for general guidance on log source classification, including the standard combinations of product, category, and service.

Metadata

The metadata block captures authorship, lifecycle, and descriptive information about the rule. It is separate from detection logic; nothing in metadata affects whether a rule fires. Its purpose is to make rules discoverable, attributable, and useful to analysts when a finding appears.

MITRE ATT&CK

The mitre block maps a rule to MITRE ATT&CK tactics, techniques, and subtechniques. Each field is an array of ID strings:

Compliance

The compliance block maps a rule to one or more compliance frameworks. Each key is a normalized framework identifier, and its value is an array of requirement ID strings.

gdpr:
  - Art. 32
  - Art. 25

pci_dss:
  - "2.2.1"
  - "6.3.3"

cmmc:
  - AC.1.001

nist_800_53:
  - AC-3
  - AU-2

nist_800_171:
  - 3.1.1
  - 3.3.1

hipaa:
  - 164.312(a)(1)

iso_27001:
  - A.8.16
  - A.9.4.2

nis2:
  - Art. 21
  - Art. 23

tsc:
  - CC6.1
  - CC7.2

fedramp:
  - AC-2
  - SI-4

Dynamic event field referencing

A Sigma rule's metadata is normally static: the title, tags, mitre, and compliance blocks describe the rule itself and are attached unchanged to every finding it generates. Wazuh extends Sigma with dynamic event field referencing, allowing those metadata fields to embed placeholders that resolve against the triggering event at enrichment time. This process is known as Interpolation. Interpolation means taking static text in your rule YAML and replacing placeholders with values from the current event at detection time, so the final string is dynamically built for each event.

Each finding is written to the wazuh-findings-v5-{logtype}-* index and reflects the specific context of the matched event. For example, the Wazuh agent ID, hostname, or any other field present in the normalized event.

Syntax

You can insert {{ field.path }} placeholders into certain rule metadata fields. When a rule script executes, Wazuh replaces those placeholders with the actual values from the triggering event before writing the finding to the index.

metadata:
  title: "Apache segmentation fault in agent {{ wazuh.agent.id }}"

If the event has wazuh.agent.id = "001", the stored finding title becomes: "Apache segmentation fault in agent 001"

id: ed85157d-711b-4edb-8390-492ec63c92ac
sigma_id: 12345678-90ab-cdef-1234-567890abcdef
logsource:
  product: apache-http
tags:
  - attack.impact
  - attack.t1499.004
  - "{{ wazuh.agent.host.name }}"
level: high
status: test
detection:
  condition: selection
  selection:
    message|contains:
      - exit signal Segmentation Fault
    wazuh.integration.name: apache-http
metadata:
  title: "Apache segmentation fault in agent {{ wazuh.agent.id }}"
  description: Segmentation faults raised by an Apache worker process.
mitre:
  tactic:
    - TA0040
  technique:
    - T1499
  subtechnique:
    - T1499.004
compliance:
  pci_dss:
    - "6.2"
    - "11.4"

{
  "title": "Apache segmentation fault in agent 001",
  "tags": ["attack.impact", "attack.t1499.004", "web-prod-01"],
  "mitre": {
    "tactic": ["TA0040"],
    "technique": ["T1499"],
    "subtechnique": ["T1499.004"]
  },
  "compliance": {
    "pci_dss": ["6.2", "11.4"]
  }
}