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 logon
name: failed_logon
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4625
  condition: selection
---
title: Successful logon
name: successful_logon
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
  condition: selection
---
title: Burst of failed logons
name: many_failed_logons
status: experimental
correlation:
  type: event_count
  rules:
    - failed_logon
  group-by:
    - TargetUserName
    - IpAddress
  timespan: 10m
  condition:
    gte: 5
---
title: Failures followed by success (possible brute force)
status: experimental
correlation:
  type: temporal_ordered
  rules:
    - many_failed_logons
    - successful_logon
  group-by:
    - TargetUserName
    - IpAddress
  timespan: 1h
falsepositives:
  - Corporate VPN with legitimate retries
level: medium
tags:
  - attack.credential-access
  - attack.t1110.001

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. When several events have to be linked, correlation comes in.

A correction. The first version of this article used a single rule with condition: fail and success. That rule never fires: the condition is evaluated on each event separately, and no event is both a 4625 and a 4624. «First this, then that» is a correlation: event_count counts the failures and temporal_ordered requires the success to come afterwards.

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