What is Sigma, and how would you turn a hunt finding into a portable detection rule?

Sigma is to detections what YARA is to files: a portable, human-readable way to express what malicious activity looks like in logs, independent of any single SIEM. You write the logic once and convert it to whatever query language your stack speaks.

Anatomy of a rule

A Sigma rule is YAML with a few key sections:

• Metadata — title, id, status, level (informational → critical), description, author, tags (often ATT&CK technique IDs like attack.t1059).
• logsource — where to look: category (e.g. process_creation), product (e.g. windows), optionally service.
• detection — one or more named selections of field/value matches, plus a condition that combines them logically.
• falsepositives and fields — guidance for the analyst who triages a hit.

From hunt to rule

When a hunt surfaces a real technique, codify it. Say you found malicious use of rundll32.exe loading from a temp path: write a selection matching Image ending in rundll32.exe and CommandLine containing the temp path pattern, then a condition. Tag it with the ATT&CK technique so coverage is trackable.

Keeping it precise

A rule that matches too broadly buries the SOC in false positives and gets disabled. Anchor on attacker-specific fields, exclude known-good parents, set a sensible level, and document expected false positives so triagers know what is normal.

Why this matters

Interviewers want detection-as-code thinking: portable, version-controlled, ATT&CK-mapped rules — not point-and-click searches that live only in one console and one person's head.