Turn "I’d recognize that attack" into an automated rule. Sigma is the vendor-neutral language for detections — write once, convert to any SIEM, and share with the community.
Why: every SIEM has its own rule syntax, which locks your detections in — Sigma is a vendor-neutral YAML format for detection rules that converts to Splunk, Elastic, Sentinel, and more, so you write a detection once and share it. When: author detections in Sigma and convert them to your SIEM’s query language. Where: a large open ruleset already exists, so you start from community detections, not a blank page.
# A Sigma rule: detect many failed logins from one source (brute force).
title: Multiple Failed Logins From Single Source
status: experimental
logsource:
category: authentication
detection:
failures:
event.outcome: failure
timeframe: 5m
condition: failures | count() by src_ip > 20
level: medium
tags:
- attack.credential_access
- attack.t1110 # MITRE ATT&CK: Brute ForceWhy: a good detection is specific enough to avoid drowning analysts in false positives, yet general enough to catch variants — and it must be documented (what it catches, why, and how to respond). When: describe the behavior, define precise match conditions, set a severity, and note the ATT&CK technique. Where: behavior-based rules (what the attacker DOES) survive far better than signature rules (a specific hash or string) that attackers trivially change.
A durable detection rule:
TITLE + DESCRIPTION what behavior it catches and why it's suspicious
LOGSOURCE which data it needs (must actually be collected!)
CONDITION specific enough to avoid FP floods, general enough
to catch variants
LEVEL severity, so triage can prioritize
ATT&CK TAG the technique, for coverage tracking
RESPONSE what an analyst should do when it fires
Detect BEHAVIOR (what they do), not brittle signatures (a hash/string).Why: a Sigma rule becomes useful once converted to your SIEM’s query and deployed as a scheduled search or alert — the tooling does the translation for you. When: convert with the Sigma CLI, review the generated query, then schedule it. Where: treat rules as code — version them in git, review changes, and test before deploying, exactly like the eval/CI discipline in other tracks.
# Convert a Sigma rule to your SIEM's query language:
sigma convert -t splunk rules/brute_force.yml # -> SPL
sigma convert -t esql rules/brute_force.yml # -> Elastic
# Then: schedule it as an alert, and keep rules in git (review + version).
# Detection-as-code: PRs, tests, and history for every rule change.