From a log to a detection that works in any SIEM

During an investigation you spot the pattern: a 4625 followed by a 4624 from the same IP, or a PowerShell with -enc. Good. Now turn it into a permanent detection. And here comes the usual problem: you write it in KQL and it only works for Sentinel; your colleague needs it in SPL for Splunk; the next person, in Elastic. The same work three times, three places to drift out of sync.

Sigma: the "YAML of detections"

Sigma is an open, vendor-neutral format for detection rules. You write the logic once, in readable YAML, and a converter translates it into your SIEM's language: KQL, SPL, Elastic's Lucene/EQL, Wazuh… It is to detections what YARA rules are to files: portable and shareable. That is why vendors, CERTs and projects like the official Sigma rules repo publish them.

Anatomy of a rule

title: Failed login followed by success (possible brute force)
status: experimental
logsource:
  product: windows
  service: security
detection:
  fail:
    EventID: 4625
  success:
    EventID: 4624
  condition: fail and success
fields: [IpAddress, TargetUserName]
falsepositives:
  - Corporate VPN with legitimate retries
level: medium
tags:
  - attack.credential_access
  - attack.t1110

The pieces that matter: logsource (where events come from), detection with one or more selections and a condition that combines them, the level (severity) and —crucially— falsepositives and the MITRE ATT&CK tags, which pin the rule to a concrete technique.

From log to rule, step by step

1. Isolate the event in the real log: which fields identify it (EventID, process image, command line, port…).
2. Write the selection with those fields. Be specific: Image|endswith: '\powershell.exe' and CommandLine|contains: '-enc' beats searching for just "powershell".
3. Define the condition (one selection, several with and/or, or exclusions with not filter).
4. Map to ATT&CK and document the false positives you already know.
5. Convert and test in your SIEM before trusting it.

The real enemy: false positives

A rule that fires a hundred times a day is not a detection, it is noise the analyst learns to ignore —and that is exactly where the real attack slips through—. Precise selections, exclusions of known-legit activity, and an honest level separate a useful rule from one that ends up muted.

Checklist

• ✅ Is the detection tied to ONE SIEM? Write it in Sigma and convert it.
• ✅ Specific selection (image + arguments + fields), not loose keywords.
• ✅ Clear condition; use not to exclude known-legit activity.
• ✅ Map to MITRE ATT&CK and fill in falsepositives.
• ✅ Test it with a real event before deploying.

Writing in Sigma is not one more layer of work: it is writing once instead of three times, and leaving the detection where anyone —including you six months from now— can read it and carry it to their platform.

Sergio Belmonte Morales
Cybersecurity Analyst · SOC · Sentinel/KQL specialist