What is Sigma and how do I write a detection?

What is Sigma? Sigma is a vendor-neutral rule format for writing detections against security logs. Instead of building the same logic separately for every SIEM, you define the behavior once in a structured rule and then translate it for your platform. If you want to know how to write a Sigma detection, the short version is this: start with good telemetry, describe a real attacker behavior, test the logic against real logs, and tune it before production.

What Sigma is

Sigma is often described as a generic signature format for security logs. Its main value is portability. Rather than tying a rule to one backend from the start, you write the detection in a common format and translate it later.

That makes Sigma useful for:

• detection engineering
• content sharing across tools
• rule review and collaboration
• documenting detection logic clearly
• maintaining a library of reusable detections

Sigma is not the alerting engine itself. It is a rule format that describes what suspicious behavior to look for.

For a broader detection context, see what is detection engineering.

What a Sigma rule contains

A typical Sigma rule includes both metadata and detection logic. Common fields include:

• title
• id
• status
• description
• references
• logsource
• detection
• falsepositives
• level
• tags

In practice, the two most important sections are the log source and the detection logic.

Logsource

The logsource section tells you what kind of logs the rule expects. Examples include:

• Windows process creation events
• PowerShell logs
• Linux audit logs
• cloud audit logs
• firewall logs
• web server logs

If your environment does not collect the relevant data, the rule will not work no matter how good the logic is.

Detection

The detection section contains the actual matching logic. This is where you define the fields, values, keywords, or combinations that represent suspicious activity.

Conceptually, a Sigma detection might look for:

• a process name like powershell.exe
• command-line arguments that indicate encoding or obfuscation
• a suspicious parent-child process relationship
• an unexpected administrative action in cloud logs

The exact field names depend on how your telemetry is normalized and how the backend maps the rule.

How Sigma differs from native SIEM rules

A native SIEM rule is built directly for one product. Sigma rules are designed to be portable.

That means:

• Sigma describes the detection behavior in a common format
• a converter or translation pipeline turns it into platform-specific syntax
• analysts can review one version of the logic instead of maintaining separate copies from scratch

That portability is helpful, but it does not remove the need for field mapping, query validation, and environment-specific tuning.

If you are comparing approaches, see sigma vs native siem rules.

How to write a Sigma detection

Writing a good Sigma rule is less about clever syntax and more about choosing the right behavior and telemetry.

Start with observable behavior

Do not start with a broad label like “detect malware.” Start with something you can actually see in logs.

Better starting points include:

• PowerShell launched with encoded commands
• rundll32.exe executing from suspicious paths
• scheduled task creation from unusual parent processes
• admin tools used from non-admin workstations
• failed logins followed by a successful high-risk login
• unexpected token or role changes in cloud audit logs

The more concrete the behavior, the easier it is to build and validate the rule.

Confirm the telemetry exists

Before writing the rule, verify:

• the needed log source is enabled
• the right fields are present
• field values are normalized consistently
• the events are retained long enough for testing
• normal activity does not overwhelm the signal

Many weak detections fail because the author assumes the logs exist or that field names mean the same thing everywhere.

Build readable selections

Sigma rules commonly define one or more named selections and then combine them with a condition.

For example, conceptually:

• selection_process for a suspicious process name
• selection_args for suspicious command-line content
• filter_known_good for approved admin tools or scripts
• condition to match suspicious patterns while excluding expected noise

The rule should be easy to read and easy to review. If another analyst cannot quickly understand the logic, it is probably too complicated.

Add realistic false positives

The falsepositives section should reflect real operational noise, not just theory. Common examples include:

• admin scripts
• software deployment tools
• vulnerability scanners
• backup agents
• endpoint security tooling
• approved automation

Be honest here. A noisy but well-documented rule is easier to improve than a supposedly perfect rule that floods analysts later.

Set the severity carefully

The level field should match what the behavior actually means.

Examples:

• a likely persistence technique may justify a higher severity
• a broad hunting rule may be medium or low until enriched with other signals
• a known-administrative action from an unexpected host may depend on context

If every rule is marked high, your severity scale loses value.

Test before production

Before you deploy a rule broadly:

• run it against historical data
• measure how often it matches
• inspect true positives and false positives
• verify the translated query in the target platform
• confirm the alert is useful to analysts

A rule that converts successfully but generates unusable noise is not finished.

What makes Sigma rules effective

Strong SIEM detection rules written in Sigma usually have a few things in common:

• they focus on meaningful attacker behavior
• they rely on stable, available telemetry
• they are simple enough to review
• they include clear filters for known-good activity
• they are tested in the real environment
• they are maintained as the environment changes

In other words, good detection content is usually built on operational discipline, not just syntax.

Common mistakes when writing Sigma rules

Several mistakes show up often in early Sigma syntax work:

• writing rules before validating the log source
• matching on weak keywords with no context
• skipping false positive documentation
• assuming field names are identical across tools
• overfitting to one malware sample or blog post
• deploying without testing against production-like data

The best way to avoid these mistakes is to treat Sigma as part of a detection lifecycle: hypothesis, telemetry validation, rule writing, testing, tuning, and review.

Common misconceptions

“Sigma is a SIEM”

No. Sigma is a portable rule format, not a detection platform.

“If I write a Sigma rule, it works everywhere”

Not automatically. It still depends on telemetry quality, field mapping, backend support, and query translation.

“Sigma replaces testing”

No. You still need to validate every rule against real logs and tune it for your environment.

“More complex rules are better”

Usually not. The most useful rules are often clear, behavioral, and scoped well enough to be trusted.

“A Sigma rule guarantees high-fidelity detection”

No. Detection quality depends on the logs, the environment, the behavior being matched, and how well the rule is tuned.

Final takeaway

If you are asking what is Sigma, think of it as a common language for log-based threat detection. If you are asking how to write a Sigma detection, start with the data you actually have, focus on observable attacker behavior, keep the logic readable, and test aggressively. Sigma helps make detections more portable and reviewable, but the real craft is still in choosing the right behavior and tuning it until analysts can trust the alert.

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.