Sigma rules

Vendor-agnostic detections compiled to any SIEM.

Sigma is to detections what a common language is to trade: a generic, vendor-agnostic rule format that you write once and compile to whatever SIEM you run. It is the practical foundation of portable, shareable detection as code.

Write once, target many

A Sigma rule is YAML with two essential parts: a logsource (which telemetry it applies to — a product, service, or category) and a detection (a selection describing the pattern and a condition combining selections). A converter — pySigma with a backend for your platform — compiles that rule into the target’s query language and field schema: Splunk SPL, Elastic Query DSL, Microsoft Sentinel KQL, and more. This decouples the detection logic from the platform, so a rule is not locked to one vendor and can be shared across teams and the wider community.

title: AWS console login without MFA
logsource: { product: aws, service: cloudtrail }
detection:
  selection:
    eventName: ConsoleLogin
    additionalEventData.MFAUsed: 'No'
  condition: selection
level: high
 
# Compile it to your SIEM with pySigma:
#   sigma convert -t splunk   rule.yml   →  eventName=ConsoleLogin MFAUsed=No
#   sigma convert -t kusto    rule.yml   →  where eventName == "ConsoleLogin" ...
# One rule, many targets — the same logic everywhere.

Tune, do not just import

The Sigma community publishes thousands of rules, which is a huge head start — but bulk-importing them unchanged causes either noise (rules too broad for your environment) or silent gaps (rules referencing fields your pipeline does not produce). Treat community rules as a starting point: map them to your log schema, tune the selections to your telemetry, and validate that each one actually fires against your data before trusting it. Because Sigma rules are just YAML, they fit naturally into the detection-as-code pipeline — reviewed, tested, and compiled to your SIEM in CI.