Sigma Rules for Detection Engineers

Focused skills. One thing, learned properly.

Learn to write vendor-neutral detection rules that survive SIEM migration. Master the Sigma YAML specification, write detection logic that catches real attacks, convert rules to KQL, SPL, and Elastic Query DSL, and deploy them to Sentinel analytics rules.

Start Skill View Pricing

Content last updated: April 2026

Why take this course

For detection engineers and threat hunters formalising their rule-writing practice. You finish able to author portable, well-tested Sigma rules that convert to the major SIEM backends — the craft that distinguishes a detection engineer from an analyst who occasionally writes rules.

What this skill teaches

Sigma is a YAML-based format for describing log detection rules independent of any SIEM. The SigmaHQ repository contains 3,000+ community rules covering the MITRE ATT&CK matrix. Detection engineers use Sigma as a shared language — write a rule once, convert it to KQL for Sentinel, SPL for Splunk, or Elastic Query DSL for Elastic SIEM. The rule travels with you when you change platforms, and contributions go back to the community.

Most practitioners consume Sigma rules from the repository without understanding the specification well enough to write their own or debug conversion failures. This skill teaches the full authoring-to-deployment lifecycle.

What you will be able to do

1. Write Sigma rules from scratch — logsource definitions, detection logic with selections and filters, field modifiers, aggregation conditions, and complete metadata with ATT&CK tags.

2. Choose detection patterns that produce actionable alerts — not rules that fire on every legitimate admin action. Understand the false positive profile of every rule you write.

3. Convert Sigma rules to KQL (Sentinel), SPL (Splunk), and Elastic Query DSL using sigma-cli. Understand why conversions fail and how to fix backend-specific field mapping issues.

4. Test rules against log samples before deployment — validate detection logic, measure false positive rates, and verify field mappings for your target SIEM.

5. Deploy converted rules as Sentinel analytics rules with correct severity, entity mapping, and incident creation settings. Manage rule lifecycle: creation, tuning, retirement.

Skill at a glance

Format: Ridgeline Skill — focused, practical, one topic

Sections: 6 content sections + guided lab

Tier: Premium subscription

Prerequisites: Basic YAML knowledge (if you've edited a config file, you have enough). Familiarity with at least one SIEM query language. The Detection Engineering course gives you the detection methodology that makes every Sigma rule strategically valuable, and Mastering KQL deepens the query language that most Sigma rules convert to.

Typical pace: 1-2 weeks at a few hours per week

MITRE ATT&CK coverage: 12 techniques mapped

What you leave with

Rule templates: Sigma rule templates for the five most common detection categories — process creation, network connection, file creation, registry modification, and authentication anomaly — ready to adapt for your environment.

Conversion pipeline: A tested workflow from Sigma YAML to deployed Sentinel analytics rule, including field mapping configuration, backend selection, and output validation.

Detection pack: The guided lab produces a 5-rule detection pack for a realistic attack chain — from initial access through persistence to lateral movement — deployable in your Sentinel workspace.

What this course does NOT cover

Deliberate scope boundaries. If any of these is your primary need, the sibling course is the better fit.

Detection engineering program design — see Detection Engineering
KQL native rules in Sentinel — see Mastering KQL for Cybersecurity

Sections

Six focused sections plus a guided detection engineering lab. Every rule targets attack patterns from the Northgate Engineering investigation thread.

SG0.1

Rule Syntax and Structure — The YAML anatomy of a Sigma rule: title, status, logsource, detection, fields, falsepositives, level, tags. The logsource abstraction: category, product, service — and why it matters for cross-platform portability. Six worked rules from "Hello World" process creation to a multi-condition lateral movement detection.

SG0.2

Detection Logic: Selections, Filters, and Conditions — The detection block in depth: named selections with field-value pairs, filters that exclude known-good activity, the condition expression that combines them. Field modifiers: contains, startswith, endswith, re, base64, all. Aggregation with count, near. Pipe operators. NE scenario: build a detection for encoded PowerShell execution with admin-activity exclusions.

SG0.3

Writing Rules That Work in Production — The difference between a rule that detects an attack in a lab and one that produces actionable alerts in a 10,000-endpoint environment. Stable vs volatile detection patterns. The false positive profile: documenting, measuring, and tuning. Field availability across platforms — what Sysmon provides that native Windows logging doesn't. Rule quality checklist. NE scenario: write a persistence detection that fires on attacker-created scheduled tasks but not on SCCM deployments.

SG0.4

Converting Sigma to KQL, SPL, and Elastic — The sigma-cli tool: installation, backends, pipelines, and field mapping configuration. Converting to KQL (Microsoft Sentinel), SPL (Splunk), and Elastic Query DSL. Why conversions fail: unmapped fields, unsupported modifiers, backend-specific limitations. Custom field mappings for your environment. Batch conversion for rule sets. NE scenario: convert a 5-rule detection pack to KQL and validate the output queries.

SG0.5

Testing and Rule Quality — Validating rules before deployment: sigma check for syntax validation, testing against log samples, measuring detection coverage against ATT&CK. The Sigma taxonomy and how it enables automated testing. Rule quality tiers: test, stable, experimental. Coverage gap analysis: mapping your rule set against ATT&CK and identifying missing detections. SIGMAC vs sigma-cli: the migration and why it matters.

SG0.6

Production Deployment in Sentinel — From converted KQL to live analytics rule. Sentinel analytics rule configuration: frequency, lookback, severity, entity mapping, incident creation, alert grouping. Importing Sigma-converted rules via the Sentinel API and ARM templates. Rule lifecycle: new rule in test mode (alert without incident) → tuning period → production (incident creation enabled) → retirement. ATT&CK tagging and the MITRE ATT&CK coverage workbook.

Lab

Guided Lab: Build a Detection Pack for Northgate Engineering — Intelligence reports indicate the INC-2026-0501 attacker used: encoded PowerShell for initial execution, scheduled task persistence, LSASS access for credential theft, SMB lateral movement, and data staging in a public folder. Write 5 Sigma rules covering the attack chain. Convert all 5 to KQL. Validate each query against sample logs. Deploy as Sentinel analytics rules with correct entity mapping. Produce a detection coverage report mapped to ATT&CK.

Where Sigma fits in your workflow

Sigma sits between threat intelligence and SIEM deployment. When a threat report describes an attack technique, you write a Sigma rule. When you migrate SIEMs, your Sigma rules convert to the new platform. When you contribute to the community, you share the Sigma rule — not a platform-specific query.

This skill connects to Detection Engineering (the methodology), Mastering KQL (the target query language for Sentinel), and Threat Hunting (using Sigma rules as hunt hypotheses).

What this skill is not

This is not a KQL or SPL course — those are covered in depth in the full courses. This skill teaches Sigma as the authoring format and covers conversion to target languages, but doesn't teach the target languages themselves. If you need deep KQL knowledge, take Mastering KQL alongside this skill.