What is a Sigma rule?

Sigma is a generic, open-source signature format for SIEM systems. Sigma rules are written in YAML and can be converted to queries for any SIEM platform (Splunk, Microsoft Sentinel, Elastic, QRadar) using the sigma-cli tool. This allows detection engineers to write vendor-agnostic detection logic that can be shared across the community.

How do you reduce false positives in SIEM rules?

Reduce false positives by: (1) adding specific conditions rather than broad pattern matches, (2) using allowlists for known-good processes and users, (3) correlating multiple events rather than alerting on single events, (4) tuning thresholds based on baseline data, (5) adding contextual enrichment (asset criticality, user role), and (6) implementing a formal tuning process with regular review cycles.

How should SIEM rules map to MITRE ATT&CK?

Each SIEM rule should map to one or more MITRE ATT&CK techniques using the technique ID (e.g., T1059.001 for PowerShell execution). This provides coverage visibility across the ATT&CK matrix, identifies detection gaps, and helps prioritize rule development based on the most relevant threat actor TTPs for your environment.

SIEM Rule Writing Guide

By FixTheVuln Team Peer-reviewed security content Sources: CISA, NVD, OWASP

Test Your Knowledge

CySA+ Practice Quiz Security+ Practice Quiz

← Back to Home

Key Takeaways

Good detection rules are specific, tuned, documented, and mapped to MITRE ATT&CK techniques
Sigma rules provide vendor-agnostic detection logic that works across Splunk, Sentinel, Elastic, and more
Three detection logic types: signature-based (known bad), anomaly-based (deviation from baseline), and behavioral (TTP patterns)
Every rule needs a tuning plan — expect to iterate based on your environment's baseline
Map all rules to MITRE ATT&CK for coverage analysis and gap identification

Detection Engineering Fundamentals

Writing effective SIEM rules is the core skill of detection engineering. A well-crafted rule catches real threats while minimizing false positives that cause alert fatigue. This guide covers the three types of detection logic, provides working examples in Splunk SPL, KQL (Microsoft Sentinel), and Sigma (vendor-agnostic YAML), and walks through a structured tuning methodology. Every example maps to a specific MITRE ATT&CK technique for coverage tracking.

Detection Logic Types

Type	How It Works	Strengths	Weaknesses	Example
Signature	Match known-bad patterns (IOCs, specific commands, file hashes)	Low false positives, fast to create	Cannot detect novel attacks	Alert on known malware hash in process creation
Anomaly	Detect deviation from established baselines (volume, timing, patterns)	Can detect unknown threats	Higher false positive rate, requires baselining period	Alert when login volume for a user exceeds 3x their 30-day average
Behavioral / TTP	Detect attack techniques regardless of specific tools or IOCs used	Resilient to tool changes, catches novel variants	Complex to write, requires deep understanding of attack techniques	Alert on process spawning from Office application executing encoded PowerShell

Splunk SPL Example: Brute Force Detection

MITRE ATT&CK: T1110.001 — Brute Force: Password Guessing

index=windows sourcetype=WinEventLog:Security EventCode=4625
| bin _time span=5m
| stats count as failed_attempts dc(TargetUserName) as targeted_users
    values(TargetUserName) as users by src_ip, _time
| where failed_attempts > 10 AND targeted_users >= 3
| eval severity=case(
    failed_attempts > 50, "Critical",
    failed_attempts > 25, "High",
    failed_attempts > 10, "Medium",
    1=1, "Low"
)
| table _time, src_ip, failed_attempts, targeted_users, users, severity
| sort -failed_attempts

Logic: Windows Event ID 4625 (failed logon) events grouped into 5-minute windows. Alerts when a single source IP generates more than 10 failures against 3 or more distinct accounts — a strong indicator of password spraying or brute force.

KQL Example (Microsoft Sentinel): Suspicious PowerShell

MITRE ATT&CK: T1059.001 — Command and Scripting Interpreter: PowerShell

DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "powershell.exe" or FileName =~ "pwsh.exe"
| where ProcessCommandLine has_any (
    "-EncodedCommand", "-enc ", "FromBase64String",
    "IEX", "Invoke-Expression", "DownloadString",
    "Net.WebClient", "Invoke-WebRequest",
    "Start-BitsTransfer", "hidden", "-w hidden"
)
| where InitiatingProcessFileName in~ (
    "winword.exe", "excel.exe", "outlook.exe",
    "powerpnt.exe", "mshta.exe", "wscript.exe"
)
| project Timestamp, DeviceName, AccountName,
    InitiatingProcessFileName, FileName, ProcessCommandLine
| sort by Timestamp desc

Logic: Detects PowerShell launched by Office applications or script hosts with suspicious command-line arguments (encoded commands, download cradles, hidden windows). This is a classic initial access / execution pattern.

Sigma Rule: Credential Dumping via LSASS Access

MITRE ATT&CK: T1003.001 — OS Credential Dumping: LSASS Memory

title: Suspicious LSASS Process Access
id: 8f5b02a0-6d12-4b5a-9e3c-1a2b3c4d5e6f
status: stable
description: |
    Detects processes accessing LSASS memory, which may indicate
    credential dumping tools like Mimikatz, ProcDump, or comsvcs.dll.
references:
    - https://attack.mitre.org/techniques/T1003/001/
author: FixTheVuln
date: 2026/03/06
tags:
    - attack.credential_access
    - attack.t1003.001
logsource:
    category: process_access
    product: windows
detection:
    selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess|contains:
            - '0x1010'
            - '0x1038'
            - '0x1fffff'
            - '0x40'
    filter_system:
        SourceImage|startswith:
            - 'C:\Windows\System32\'
            - 'C:\Windows\SysWOW64\'
        SourceImage|endswith:
            - '\svchost.exe'
            - '\csrss.exe'
            - '\wininit.exe'
            - '\MsMpEng.exe'
    filter_av:
        SourceImage|contains:
            - '\Microsoft\Windows Defender\'
            - '\CrowdStrike\'
            - '\SentinelOne\'
    condition: selection and not filter_system and not filter_av
falsepositives:
    - Legitimate security tools accessing LSASS
    - System processes during updates
level: high

Note: This Sigma rule can be converted to any SIEM platform using sigma convert. The filter sections exclude known-good system processes and common AV/EDR products to reduce false positives.

MITRE ATT&CK Mapping

Every detection rule should map to at least one ATT&CK technique. This enables coverage analysis and gap identification across the kill chain.

Tactic	Technique	ID	Detection Approach
Initial Access	Phishing: Spearphishing Attachment	T1566.001	Email gateway + Office child process monitoring
Execution	PowerShell	T1059.001	Script block logging + suspicious command-line args
Persistence	Registry Run Keys	T1547.001	Registry modification events for Run/RunOnce keys
Privilege Escalation	Token Manipulation	T1134	Process token change events + unusual privilege assignments
Defense Evasion	Indicator Removal: Clear Event Logs	T1070.001	Windows Event ID 1102 (audit log cleared)
Credential Access	LSASS Memory	T1003.001	Process access to lsass.exe with specific access masks
Lateral Movement	Remote Services: SMB	T1021.002	Network logon events + new SMB connections to sensitive hosts
Exfiltration	Exfiltration Over Web Service	T1567	Unusual outbound data volume to cloud storage domains

Tuning Methodology

Every rule requires tuning after deployment. Use this structured process to minimize false positives while maintaining detection efficacy.

Step	Action	Details
1. Deploy in Alert-Only	Enable the rule but do not trigger automated response	Run for 1-2 weeks to collect baseline alert data
2. Analyze False Positives	Review every alert and categorize as true positive, false positive, or benign true positive	Document the reason for each false positive (known tool, scheduled task, legitimate admin activity)
3. Build Allowlists	Add verified benign sources to filter conditions	Use specific identifiers (process path + hash) not broad exclusions (entire user accounts)
4. Adjust Thresholds	Modify count/time window thresholds based on observed baseline	Set thresholds above the 99th percentile of normal behavior
5. Validate Detection	Run atomic tests or purple team exercises to confirm the rule still catches real attacks	Test with both common tools and modified variants
6. Promote to Production	Enable automated response and escalation workflows	Document final rule logic, tuning decisions, and remaining known FP rate

Explore More Blue Team Guides

For comprehensive tutorials and security guides:

Visit FixTheVuln.com →

Related Resources

🎯 Threat Hunting for Beginners Turn SIEM alerts into proactive hunting hypotheses 📋 Log Analysis Cheat Sheet Know which logs to query in your SIEM rules 🚨 Incident Response Guide What happens after your SIEM rule fires

FixTheVuln Store

Study Planners Available for Both Certs

Fillable PDF study planners with domain trackers, weekly schedules, and progress tracking. Available in Standard, ADHD-Friendly, Dark Mode, and 4-Format Bundle.

CompTIA CySA+ Planner GIAC GCIH Planner

60+ certifications available — from $5.99

FixTheVuln Store

Patch Tuesday Sprint Kit

5 fillable templates for vulnerability triage, sprint planning, testing, SLA tracking, and executive reporting. Free blank templates or $4.99/mo for pre-filled intelligence with real CISA KEV data.

Try Free Templates Subscribe — $4.99/mo

CyberFolio

Choosing your next cert? Track them all in one place.

Build a shareable cybersecurity portfolio that highlights your certifications, projects, and skills — free.

Build Your Portfolio →