Last reviewed:
A Sigma rule should describe observable attacker behaviour. If the evidence is too thin, a patch note or hunt prompt may be the better output.
Sigma is good at expressing log patterns. It is poor at inventing evidence. Before writing a rule, name the log source, the field and the behaviour the attacker must perform.
A CVE can be severe and still make a bad rule candidate. Some exploits leave almost no product-side log trail. Others are better caught by the action after exploitation, such as a new process, credential change or data access event.
No-rule decisions should be explicit. They are not failures; they stop the team publishing detections that only look useful in a spreadsheet.
A declined Sigma rule can still produce useful work. Write a patch-priority note, exposure query, hunt prompt or monitoring checklist. Those outputs are easier to trust than a brittle detector with a grand title.
When exploitation details improve, reopen the item. The decision can change if a vendor publishes request patterns, public PoC behaviour, audit events or IoCs that make the detection specific.
decision: no Sigma rule
reason: exploit behaviour not visible in available logs
safer_output: patch-and-monitor note
reopen_if: vendor publishes request pattern or audit event
Every low-quality rule adds review cost. Detection teams pay for that cost in tuning time, analyst attention and slower incident response.
CloudSigma should be used when the CVE or advisory points to something the SIEM can see. When it does not, the better answer is to say so plainly.