Last reviewed:
A production-ready Sigma rule is more than valid YAML. It has the right log source, fields that exist in the target SIEM, a clear false-positive story and conversion output an analyst can run.
A Sigma rule can parse cleanly and still be unsafe to ship. The syntax check tells you the rule follows the format. It does not tell you whether the log source exists, whether the field names survive conversion or whether the detection will fire on every administrator task.
Production review starts with the behaviour. Name the attacker action first, then check whether the rule actually observes that action in logs. If the rule only detects a weak precondition, mark it as context rather than direct detection coverage.
The log source is the contract between the rule and the SIEM. For cloud work, that might be AWS CloudTrail, Azure Activity logs, Entra ID sign-ins, GCP Cloud Audit Logs or a SIEM-normalised table. The rule should say which source it expects and which event family it reads.
Weak rules blur this point. They look for a field that only exists after a vendor parser has renamed it, or they mix endpoint and cloud fields in the same selection. A reviewer should reject that until the field mapping is explicit.
A rule is not ready until it converts to the SIEM dialect the customer runs. Splunk SPL, Sentinel KQL, Google SecOps YARA-L, Elastic and OpenSearch each have different field names and query limits. Conversion can expose problems that a Sigma parser misses.
CloudSigma checks conversion as part of publication review. Operators should still test the converted query against their own data, because parser packs and normalisation choices vary by tenant.
[ ] Sigma parses cleanly
[ ] Log source exists in the target environment
[ ] Selected fields exist after ingestion
[ ] Query converts to the target SIEM dialect
[ ] False positives name known-good activity
[ ] Level is medium or higher for published showcase use
The falsepositives section should name the legitimate behaviour that looks like the attack. 'Administrative activity' is too vague. 'Break-glass role assignment during an approved incident' gives a SIEM engineer something real to suppress.
Do not fix noise by removing the attacker behaviour from the condition. Tune around known-good users, service accounts, automation hosts and maintenance windows. The rule should still catch the same technique after tuning.