Sigma Rule Tutorial: Your First Detection Engineering Win
When I started detection engineering, I wasted hours copy-pasting vendor-specific queries that broke every time we switched SIEMs. Then I found Sigma. This Sigma rule tutorial is the guide I wish I had on day one: it walks through writing your first detection-engineering rule in YAML and doing a clean Sigma to SPL conversion for Splunk. Sigma is the generic, portable signature format for SIEMs, the same way Snort is for IDS. Write one rule once, convert it to Splunk, QRadar, or Elastic, and stop re-authoring the same logic five times.
Why Sigma Beats Vendor Lock-In
Maintaining separate detection logic for Splunk SPL and QRadar AQL means every new rule means duplicating work and introducing drift between platforms. Sigma fixes that. A single YAML file feeds sigma-cli, which compiles to 20+ backends. Migrating legacy vendor-specific saved searches into Sigma cuts maintenance overhead and makes rule reviews reproducible, since reviewers are looking at the same portable YAML instead of platform-specific syntax. It also maps cleanly to MITRE ATT&CK, so every detection ties back to a technique ID for coverage tracking.
Anatomy of a Sigma Rule
A Sigma rule is just structured YAML with a handful of required fields: title, logsource, detection, and condition. The logsource tells the converter which data you're targeting (e.g., product: windows, service: security). The detection block holds one or more search identifiers, and the condition combines them with boolean logic. Add level (informational to critical), tags for ATT&CK mapping like attack.t1059.001, and a falsepositives list so analysts triaging the alert know what to expect. Keep titles short and descriptive; they become the alert name your SOC sees at 3 AM.
Writing Your First Rule
Let's detect suspicious PowerShell encoded commands (ATT&CK T1059.001). Create suspicious_powershell.yml: title: Suspicious PowerShell Encoded Command logsource: product: windows category: process_creation detection: selection: Image|endswith: '\powershell.exe' CommandLine|contains: - '-enc' - '-EncodedCommand' condition: selection level: high tags: - attack.execution - attack.t1059.001 falsepositives: - Legitimate admin scripts using encoded blocks The |endswith and |contains modifiers handle path and substring matching so you don't hardcode brittle full strings. Start narrow, then widen as you validate against real telemetry.
Sigma to SPL Conversion
Now convert it. Install the tooling with pip install sigma-cli and the Splunk plugin via sigma plugin install splunk. Then run: sigma convert -t splunk suspicious_powershell.yml You'll get valid SPL like: Image="*\\powershell.exe" (CommandLine="*-enc*" OR CommandLine="*-EncodedCommand*"). Drop it into a Splunk saved search, add your index and sourcetype, and schedule it. The same file converts to QRadar AQL or Elastic Query DSL with a flag change. This Sigma to SPL conversion workflow is what turns one-off detections into a version-controlled, Git-managed rule library.
Test Before You Deploy
Never ship an untested rule. Validate every Sigma rule three ways: run sigma check to catch schema errors, generate the SPL and test it against historical data to measure false-positive volume, and use Atomic Red Team to fire the actual technique and confirm the alert triggers. That kind of testing catches noisy rules before they ever reach production. A rule that pages analysts on legitimate admin activity is worse than no rule at all.
Your Next Step
Fork the SigmaHQ repository, pick one ATT&CK technique relevant to your environment, and write a single rule end-to-end today, from YAML to a tested Sigma to SPL conversion in your SIEM. Commit it to Git, tag the ATT&CK ID, and you've started a real detection-engineering pipeline. Build ten of these and you'll have a portable, auditable detection library that outlives any SIEM vendor. That's the foundation everything else in detection engineering is built on.