Sigma Rules

Sigma is an open standard for writing detection rules. Think of it as “YARA for logs” — a vendor-agnostic format that can be converted to any SIEM’s query language.

Why Sigma?

Vendor-neutral — Write once, deploy to Splunk, Sentinel, Elasticsearch, Chronicle, OpenSearch, or Google SecOps
Community-driven — Thousands of shared rules in the SigmaHQ repository
Structured — YAML format with defined fields for logsource, detection, and metadata
Tooling — pySigma provides validation and conversion

Rule Anatomy

Here is a complete Sigma rule with annotations:


title: AWS IAM Access Key Creation               # Human-readable title
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890         # Unique identifier (UUID)
status: experimental                               # experimental, test, stable
description: |                                     # Detailed description
  Detects the creation of a new IAM access key,
  which may indicate persistence via T1098.001.
references:
  - https://attack.mitre.org/techniques/T1098/001/
author: CloudSigma                                 # Rule author
date: 2026/02/14                                   # Creation date
tags:                                              # MITRE ATT&CK mapping
  - attack.persistence
  - attack.t1098.001
logsource:                                         # Where to look
  product: aws
  service: cloudtrail
detection:                                         # What to look for
  selection:
    eventName: CreateAccessKey
  condition: selection                             # Boolean logic
falsepositives:                                    # Known benign triggers
  - Legitimate key rotation by administrators
level: medium                                      # informational, low, medium, high, critical

Key Sections

Section	Purpose
`title`	Short, descriptive name for the detection
`logsource`	Identifies the log type (`product` + `service` or `category`)
`detection`	The matching logic — field-value pairs combined with boolean conditions
`tags`	MITRE ATT&CK technique and tactic mappings
`level`	Severity: `informational`, `low`, `medium`, `high`, `critical`
`falsepositives`	Expected benign matches to reduce alert fatigue

Detection Logic

The detection section uses named selections combined in a condition:


detection:
  selection_action:
    eventName:
      - CreateAccessKey
      - CreateLoginProfile
  filter_service:
    userIdentity.invokedBy: "*.amazonaws.com"
  condition: selection_action and not filter_service

This detects CreateAccessKey or CreateLoginProfile events unless invoked by an AWS service.

SIEM Conversion

Sigma rules are converted to SIEM-native queries via pySigma backends:

SIEM	Backend	Output Example
Splunk	`splunk`	`index=cloudtrail eventName=CreateAccessKey`
Microsoft Sentinel	`sentinel`	`CloudTrailLogs \| where EventName == "CreateAccessKey"`
Elasticsearch	`elasticsearch`	`eventName:"CreateAccessKey"`
Google Chronicle	`chronicle`	UDM Search query format
OpenSearch	`opensearch`	Lucene / DQL query format
Google SecOps	`google_secops`	YARA-L rule format

CloudSigma runs these conversions automatically for every generated rule. You receive both the Sigma YAML and the converted queries in the API response.

How CloudSigma Generates Rules

TTP extraction — Identifies which ATT&CK techniques are described in your input
Gold corpus lookup — Finds example rules for each technique and platform from a curated corpus of 475+ rules
AI generation — Uses the gold corpus examples to ground the AI, producing rules that follow correct conventions
Validation — Every rule is validated by pySigma before delivery
Conversion — Validated rules are converted to your target SIEM formats

This grounding approach produces rules that use correct field names, proper logsource mappings, and valid detection logic for each platform.