Author a Sigma Detection from a Described Threat Behavior

Tier: Core · Workflow area: Detection engineering with AI

This playbook turns a described threat behavior into a Sigma rule, then holds it to the second bar: it must fire on a known-bad sample and stay silent on known-good data before it earns a place in your rule set.

When to reach for this

• •
  You have a behavior to detect — from a threat report, an ATT&CK technique, or an incident — and want a portable, vendor-neutral rule.
• •
  You want a first draft that follows the Sigma spec so you spend your time on logic, not YAML syntax.
• •
  You are building coverage and prefer Sigma as the source of truth you later compile to your SIEM.

Skip AI when you are tweaking one field in an existing rule — edit it directly.

The workflow

1. 1.

   Describe the behavior precisely, with the log source. Vague input ("detect credential dumping") yields a generic rule that overfits to one tool. Name the data source and the observable.

   Copy

   Write a Sigma rule (current spec) for this behavior against Windows Security
   + Sysmon logs (sample data):
   
   Behavior: a non-system process accessing lsass.exe memory
   (Sysmon Event ID 10, TargetImage lsass.exe) where the source image is
   not a known LSASS-access tool.
   
   Requirements:
   - Use the standard Sigma logsource/detection/condition structure.
   - Reference only real Sysmon EID 10 fields (SourceImage, TargetImage,
     GrantedAccess, CallTrace).
   - Add a level, tags mapping to the relevant ATT&CK technique, and
     false-positive notes.
   - If a field you need is not standard for this log source, say so.
   

   Expected output: a spec-compliant Sigma rule with logsource, detection, condition, level, ATT&CK tags, and a falsepositives list.

2. 2.

   Validate the YAML against the Sigma spec. Run it through sigma check (sigma-cli) or pySigma. This catches malformed structure and unknown modifiers immediately — before you reason about detection logic.

3. 3.

   Compile it to your SIEM and inspect the query. Use pySigma to convert to your backend and read the generated query. This is where a wrong field name (Image vs SourceImage) surfaces as a query that references a column your data does not have.

4. 4.

   Test on known-bad, then known-good. Run the compiled query against a sample event that should trigger it (an Atomic Red Team artifact or a crafted sample). Then run it against benign sample logs. A rule that misses the bad or lights up on the good is not done.

5. 5.

   Tune with the false positives in hand. When benign data triggers it, feed the offending event back: "This benign event matched; tighten the condition to exclude it without losing the malicious case." Add each exclusion to the rule's falsepositives notes.

Verify before you trust it

• Field-existence check: confirm every field in the detection block is a real field for that log source. Models invent plausible Sysmon fields; the pySigma compile plus a look at your sample schema catches them.
• ATT&CK-tag check: verify the technique ID the model tagged actually matches the behavior. A rule for LSASS access tagged as T1003.001 is right; the same rule tagged as a phishing technique is a copy-paste artifact — fix it or your coverage map lies.
• False-positive catch: the known-good run is the whole verification. If the rule fires on a sanctioned EDR agent accessing LSASS, it needs that exclusion before deployment.

Pitfalls

• Overfitting to one toolname. A rule keyed on mimikatz.exe in the image name catches the demo and nothing a real attacker renames. Detect the behavior (memory access pattern), not the filename.
• Invented fields and modifiers.|contains|all and friends are easy to misuse; unknown fields compile to broken queries. Always compile and read the output.
• Wrong or missing log source. A rule written for Sysmon EID 10 is useless if your fleet does not ship Sysmon. Confirm the data exists before investing in the rule.
• Untested condition logic.selection and not filter reads fine and can still invert your intent. Only the known-bad/known-good test proves the logic.

Tools

• Sigma + pySigma / sigma-cli: the vendor-neutral rule format and the validator/compiler that turns the draft into a testable query — the free core of AI detection engineering.
• MITRE ATT&CK Navigator: confirm the technique tags and see where the new rule fits your coverage.
• Atomic Red Team: supplies safe, known-bad sample artifacts to test that the rule actually fires.

Client-safe variant

Sigma rules are portable and largely non-sensitive, which makes this one of the safest AI detection workflows for services work — but the behavior description can reveal a client's environment. Run generation on a local Ollama model or the client's approved endpoint, and describe the behavior generically (log source and observable, not client hostnames or tool inventories). Do all validation and known-bad/known-good testing against your own lab data or the client's sample indices, never their production logs. The finished Sigma rule ships into the client's detection repo with its false-positive notes intact so the next engineer sees what it was tested against.