detection-sigma

Original source / Raw SKILL.md

---
name: detection-sigma
description: >
  Generic detection rule creation and management using Sigma, the universal SIEM rule format.
  Sigma provides vendor-agnostic detection logic for log analysis across multiple SIEM platforms.
  Use when: (1) Creating detection rules for security monitoring, (2) Converting rules between
  SIEM platforms (Splunk, Elastic, QRadar, Sentinel), (3) Threat hunting with standardized
  detection patterns, (4) Building detection-as-code pipelines, (5) Mapping detections to
  MITRE ATT&CK tactics, (6) Implementing compliance-based monitoring rules.
version: 0.1.0
maintainer: SirAppSec
category: incident-response
tags: [sigma, detection, siem, threat-hunting, mitre-attack, detection-engineering, log-analysis]
frameworks: [MITRE-ATT&CK, NIST, ISO27001]
dependencies:
  python: ">=3.8"
  packages: [pysigma, pysigma-backend-splunk, pysigma-backend-elasticsearch, pyyaml]
references:
  - https://github.com/SigmaHQ/sigma
  - https://github.com/SigmaHQ/pySigma
  - https://sigmahq.io/
---

# Sigma Detection Engineering

## Overview

Sigma is to log detection what Snort is to network traffic and YARA is to files - a universal signature format for describing security-relevant log events. This skill helps create, validate, and convert Sigma rules for deployment across multiple SIEM platforms, enabling detection-as-code workflows.

**Core capabilities**:
- Create detection rules using Sigma format
- Convert rules to 25+ SIEM/EDR backends (Splunk, Elastic, QRadar, Sentinel, etc.)
- Validate rule syntax and logic
- Map detections to MITRE ATT&CK framework
- Build threat hunting queries
- Implement compliance-based monitoring

## Quick Start

### Install Dependencies

```bash
pip install pysigma pysigma-backend-splunk pysigma-backend-elasticsearch pyyaml
```

### Create a Basic Sigma Rule

```yaml
title: Suspicious PowerShell Execution
id: 7d6d30b8-5b91-4b90-a71e-4f5a3f5a3c3f
status: experimental
description: Detects suspicious PowerShell execution with encoded commands
references:
    - https://attack.mitre.org/techniques/T1059/001/
author: Your Name
date: YYYY/MM/DD
modified: YYYY/MM/DD
tags:
    - attack.execution
    - attack.t1059.001
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\powershell.exe'
        CommandLine|contains:
            - '-enc'
            - '-EncodedCommand'
            - 'FromBase64String'
    condition: selection
falsepositives:
    - Legitimate administrative scripts
level: medium
```

### Convert Rule to Target SIEM

```bash
# Convert to Splunk
python scripts/sigma_convert.py rule.yml --backend splunk

# Convert to Elasticsearch
python scripts/sigma_convert.py rule.yml --backend elasticsearch

# Convert to Microsoft Sentinel
python scripts/sigma_convert.py rule.yml --backend sentinel
```

## Core Workflows

### Workflow 1: Detection Rule Development

Progress:
[ ] 1. Identify detection requirement from threat intelligence or compliance
[ ] 2. Research log sources and field mappings for target environment
[ ] 3. Create Sigma rule using standard template
[ ] 4. Validate rule syntax: `python scripts/sigma_validate.py rule.yml`
[ ] 5. Test rule against sample logs or historical data
[ ] 6. Convert to target SIEM format
[ ] 7. Deploy and tune based on false positive rate
[ ] 8. Document rule metadata and MITRE ATT&CK mapping

Work through each step systematically. Check off completed items.

### Workflow 2: Threat Hunting Rule Creation

For proactive threat hunting based on TTPs:

1. **Select MITRE ATT&CK Technique**
   - Review threat intelligence for relevant TTPs
   - Identify technique ID (e.g., T1059.001 - PowerShell)
   - See [references/mitre-attack-mapping.md](references/mitre-attack-mapping.md) for common techniques

2. **Identify Log Sources**
   - Determine which logs capture the technique
   - Map log source categories (process_creation, network_connection, file_event)
   - Verify log source availability in your environment

3. **Define Detection Logic**
   - Create selection criteria matching suspicious patterns
   - Add filters to reduce false positives
   - Use field modifiers for robust matching (endswith, contains, re)

4. **Validate and Test**
   - Run validation: `python scripts/sigma_validate.py hunting-rule.yml`
   - Test against known-good and known-bad samples
   - Tune detection logic based on results

5. **Document and Deploy**
   - Add references to threat reports
   - Document false positive scenarios
   - Convert and deploy to production SIEM

### Workflow 3: Bulk Rule Conversion

When migrating between SIEM platforms:

```bash
# Validate all rules first
python scripts/sigma_validate.py --directory rules/ --report validation-report.json

# Convert entire rule set
python scripts/sigma_convert.py --directory rules/ --backend splunk --output converted/

# Generate deployment report
python scripts/sigma_convert.py --directory rules/ --backend splunk --report conversion-report.md
```

Review conversion report for:
- Successfully converted rules
- Rules requiring manual adjustment
- Unsupported field mappings
- Backend-specific limitations

### Workflow 4: Compliance-Based Detection

For implementing compliance monitoring (PCI-DSS, NIST, ISO 27001):

1. **Map Requirements to Detections**
   - Identify compliance control requirements
   - Determine required log monitoring
   - See [references/compliance-mappings.md](references/compliance-mappings.md)

2. **Create Detection Rules**
   - Use compliance rule templates from `assets/compliance-rules/`
   - Tag rules with compliance framework (e.g., tags: [pci-dss.10.2.5])
   - Set appropriate severity levels

3. **Validate Coverage**
   - Run: `python scripts/compliance_coverage.py --framework pci-dss`
   - Review coverage gaps
   - Create additional rules as needed

4. **Generate Compliance Report**
   - Document detection coverage by control
   - Include sample queries and expected alerts
   - Maintain audit trail for compliance evidence

## Rule Structure Reference

### Required Fields

```yaml
title: Human-readable rule name
id: UUID (generate with: python -c "import uuid; print(uuid.uuid4())")
status: stable|test|experimental|deprecated
description: Detailed description of what this detects
author: Your Name
date: YYYY/MM/DD
modified: YYYY/MM/DD
logsource:
    category: process_creation|network_connection|file_event|...
    product: windows|linux|macos|azure|aws|...
detection:
    selection:
        FieldName: value
    condition: selection
level: informational|low|medium|high|critical
```

### Optional Fields

```yaml
references:
    - https://attack.mitre.org/techniques/T1059/
tags:
    - attack.execution
    - attack.t1059.001
falsepositives:
    - Legitimate use cases
fields:
    - CommandLine
    - User
    - ParentImage
```

### Detection Conditions

```yaml
# Simple selection
detection:
    selection:
        Field: value
    condition: selection

# Multiple conditions (AND)
detection:
    selection:
        Field1: value1
        Field2: value2
    condition: selection

# OR conditions
detection:
    selection1:
        Field: value1
    selection2:
        Field: value2
    condition: selection1 or selection2

# NOT conditions
detection:
    selection:
        Field: suspicious_value
    filter:
        Field: legitimate_value
    condition: selection and not filter

# Complex logic
detection:
    selection:
        EventID: 4688
    suspicious_cmd:
        CommandLine|contains:
            - 'powershell'
            - 'cmd.exe'
    filter_legitimate:
        ParentImage|endswith: '\explorer.exe'
    condition: selection and suspicious_cmd and not filter_legitimate
```

### Field Modifiers

Common modifiers for flexible matching:

- `|contains` - Contains substring (case-insensitive)
- `|endswith` - Ends with string
- `|startswith` - Starts with string
- `|re` - Regular expression match
- `|all` - All values must match
- `|base64` - Base64-encoded value matching
- `|base64offset` - Base64 with offset variations

Example:
```yaml
detection:
    selection:
        CommandLine|contains|all:
            - 'powershell'
            - '-enc'
        Image|endswith: '\powershell.exe'
```

## Security Considerations

- **Sensitive Data Handling**: Sigma rules may reference sensitive field names or patterns. Store rules in version control with appropriate access controls. Avoid including actual sensitive data in example values.

- **Access Control**: Detection rules reveal defensive capabilities to adversaries. Implement role-based access for rule repositories. Limit rule modification to authorized detection engineers.

- **Audit Logging**: Log all rule deployments, modifications, and deletions. Track who deployed which rules to which systems. Maintain change history for compliance auditing.

- **Compliance**: Sigma rules support compliance monitoring (PCI-DSS 10.2, NIST SP 800-53 AU family, ISO 27001 A.12.4). Document rule-to-control mappings for audit evidence.

- **Safe Defaults**: Use conservative false positive filtering in production. Start rules at "experimental" status. Test thoroughly in test environment before production deployment.

## Bundled Resources

### Scripts

- `scripts/sigma_convert.py` - Convert Sigma rules to target SIEM backend formats
- `scripts/sigma_validate.py` - Validate Sigma rule syntax and detect common errors
- `scripts/compliance_coverage.py` - Analyze detection coverage for compliance frameworks
- `scripts/generate_rule_template.py` - Generate Sigma rule template with MITRE ATT&CK tags

### References

- `references/mitre-attack-mapping.md` - Common MITRE ATT&CK techniques and Sigma detection patterns
- `references/log-source-guide.md` - Log source categories, products, and field mappings
- `references/compliance-mappings.md` - Compliance framework to detection rule mappings
- `references/backend-support.md` - Supported SIEM backends and conversion capabilities
- `references/field-modifiers.md` - Comprehensive guide to Sigma field modifiers and regex patterns

### Assets

- `assets/rule-templates/` - Pre-built Sigma rule templates for common attack patterns
  - `lateral-movement.yml` - Lateral movement detection template
  - `privilege-escalation.yml` - Privilege escalation detection template
  - `persistence.yml` - Persistence mechanism detection template
  - `credential-access.yml` - Credential dumping detection template

- `assets/compliance-rules/` - Compliance-focused rule templates
  - `pci-dss-monitoring.yml` - PCI-DSS monitoring requirements
  - `nist-800-53-audit.yml` - NIST 800-53 audit logging requirements
  - `iso27001-logging.yml` - ISO 27001 logging and monitoring

## Common Detection Patterns

### Pattern 1: Process Execution Monitoring

Detect suspicious process creation with command-line analysis:

```yaml
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith:
            - '\powershell.exe'
            - '\cmd.exe'
        CommandLine|contains:
            - 'Invoke-'
            - 'IEX'
            - 'FromBase64String'
```

### Pattern 2: Network Connection Monitoring

Detect suspicious outbound connections:

```yaml
logsource:
    category: network_connection
    product: windows
detection:
    selection:
        Initiated: 'true'
        DestinationPort:
            - 4444
            - 5555
            - 8080
    filter:
        DestinationIp|startswith:
            - '10.'
            - '172.16.'
            - '192.168.'
    condition: selection and not filter
```

### Pattern 3: File Event Monitoring

Detect file creation in suspicious locations:

```yaml
logsource:
    category: file_event
    product: windows
detection:
    selection:
        TargetFilename|contains:
            - '\Windows\Temp\'
            - '\AppData\Roaming\'
        TargetFilename|endswith:
            - '.exe'
            - '.dll'
            - '.ps1'
```

## Integration Points

### CI/CD Integration

Build detection-as-code pipelines:

```yaml
# .github/workflows/sigma-validation.yml
name: Sigma Rule Validation
on: [push, pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Validate Sigma Rules
        run: |
          pip install pysigma
          python scripts/sigma_validate.py --directory rules/
      - name: Convert to Production Format
        run: |
          python scripts/sigma_convert.py --directory rules/ --backend splunk --output converted/
```

### SIEM Deployment

Automated rule deployment:
- Splunk: Use Splunk REST API or `splunk-sdk` for savedsearches
- Elasticsearch: Convert to EQL and deploy via Kibana API
- Microsoft Sentinel: Convert to KQL and deploy via Azure API
- QRadar: Convert to AQL and deploy via QRadar API

See [references/backend-support.md](references/backend-support.md) for deployment examples.

### Threat Intelligence Integration

Enrich rules with threat intel:
- Tag rules with threat actor TTPs
- Reference threat reports and IOCs
- Map to MITRE ATT&CK techniques
- Track rule effectiveness against known threats

## Troubleshooting

### Issue: Conversion Fails for Specific Backend

**Solution**: Check backend compatibility and field mappings. Some backends have limitations:
- Review `references/backend-support.md` for known limitations
- Use `sigma_convert.py --backend <backend> --debug` for detailed error output
- Check if field names are supported in target backend
- Consider custom pipeline transformations for unsupported fields

### Issue: High False Positive Rate

**Solution**: Refine detection logic with additional filters:
1. Review false positive patterns
2. Add exclusion filters for legitimate use cases
3. Use more specific field modifiers (e.g., `|endswith` vs `|contains`)
4. Consider time-based correlation for behavioral detection
5. Test with historical data to validate tuning

### Issue: Rule Not Triggering in Target SIEM

**Solution**: Verify log source availability and field mappings:
1. Confirm log source is ingested: Check SIEM data sources
2. Verify field names match: Use `sigma_convert.py --show-fields` to see mapping
3. Test converted query directly in SIEM
4. Check for case sensitivity issues in field values
5. Validate time window and search scope in SIEM

## MITRE ATT&CK Integration

Tag rules with ATT&CK tactics and techniques:

```yaml
tags:
    - attack.execution           # Tactic
    - attack.t1059.001          # Technique: PowerShell
    - attack.defense_evasion    # Additional tactic
    - attack.t1027              # Technique: Obfuscated Files
```

Common tactic tags:
- `attack.initial_access`
- `attack.execution`
- `attack.persistence`
- `attack.privilege_escalation`
- `attack.defense_evasion`
- `attack.credential_access`
- `attack.discovery`
- `attack.lateral_movement`
- `attack.collection`
- `attack.exfiltration`
- `attack.command_and_control`
- `attack.impact`

For detailed technique mappings, see [references/mitre-attack-mapping.md](references/mitre-attack-mapping.md).

## Best Practices

1. **Start with Community Rules**: Use SigmaHQ repository (3000+ peer-reviewed rules) as foundation
2. **Version Control**: Store rules in Git with meaningful commit messages
3. **Test Before Deploy**: Validate against historical data in test environment
4. **Document Tuning**: Track false positive patterns and tuning decisions
5. **Map to Frameworks**: Tag all rules with MITRE ATT&CK and compliance mappings
6. **Automate Validation**: Use CI/CD to validate rules on every change
7. **Monitor Effectiveness**: Track rule trigger rates and true positive rates
8. **Regular Updates**: Review and update rules based on new threat intelligence

## References

- [Sigma Specification](https://github.com/SigmaHQ/sigma-specification)
- [SigmaHQ Rule Repository](https://github.com/SigmaHQ/sigma/tree/master/rules)
- [pySigma Documentation](https://github.com/SigmaHQ/pySigma)
- [Sigma Converter Web Tool](https://sigconverter.io/)
- [MITRE ATT&CK Framework](https://attack.mitre.org/)


---

## Referenced Files

> The following files are referenced in this skill and included for context.

### references/mitre-attack-mapping.md

```markdown
# MITRE ATT&CK Mapping for Sigma Rules

## Table of Contents
- [Execution](#execution)
- [Persistence](#persistence)
- [Privilege Escalation](#privilege-escalation)
- [Defense Evasion](#defense-evasion)
- [Credential Access](#credential-access)
- [Discovery](#discovery)
- [Lateral Movement](#lateral-movement)
- [Collection](#collection)
- [Command and Control](#command-and-control)
- [Exfiltration](#exfiltration)
- [Impact](#impact)

## Execution

### T1059.001 - PowerShell

**Description**: Adversaries abuse PowerShell for execution

**Log Sources**: process_creation (Windows)

**Detection Pattern**:
```yaml
detection:
    selection:
        Image|endswith: '\powershell.exe'
        CommandLine|contains:
            - '-enc'
            - '-EncodedCommand'
            - 'FromBase64String'
            - 'Invoke-Expression'
            - 'IEX'
```

**Tags**:
```yaml
tags:
    - attack.execution
    - attack.t1059.001
```

### T1059.003 - Windows Command Shell

**Description**: Abuse of cmd.exe for execution

**Detection Pattern**:
```yaml
detection:
    selection:
        Image|endswith: '\cmd.exe'
        CommandLine|contains:
            - '/c'
            - '/k'
            - '&'
            - '|'
```

## Persistence

### T1053.005 - Scheduled Task

**Description**: Adversaries create scheduled tasks for persistence

**Log Sources**: process_creation, registry_event

**Detection Pattern**:
```yaml
detection:
    selection:
        Image|endswith: '\schtasks.exe'
        CommandLine|contains:
            - '/create'
            - '/sc minute'
```

### T1547.001 - Registry Run Keys

**Description**: Persistence via registry run keys

**Log Sources**: registry_event

**Detection Pattern**:
```yaml
logsource:
    category: registry_event
detection:
    selection:
        TargetObject|contains:
            - '\Software\Microsoft\Windows\CurrentVersion\Run'
            - '\Software\Microsoft\Windows\CurrentVersion\RunOnce'
```

## Privilege Escalation

### T1055 - Process Injection

**Description**: Adversaries inject code into processes

**Detection Pattern**:
```yaml
detection:
    selection:
        EventID: 8  # CreateRemoteThread
        TargetImage|endswith:
            - '\lsass.exe'
            - '\explorer.exe'
```

### T1548.002 - Bypass User Account Control

**Description**: UAC bypass techniques

**Detection Pattern**:
```yaml
detection:
    selection:
        CommandLine|contains:
            - 'eventvwr.exe'
            - 'fodhelper.exe'
        IntegrityLevel: 'High'
```

## Defense Evasion

### T1027 - Obfuscated Files or Information

**Description**: Files or information made difficult to discover or analyze

**Detection Pattern**:
```yaml
detection:
    selection:
        CommandLine|contains:
            - '-enc'
            - 'base64'
            - 'FromBase64'
            - 'convert]::FromBase64String'
```

### T1070.001 - Clear Windows Event Logs

**Description**: Clearing Windows event logs

**Detection Pattern**:
```yaml
detection:
    selection:
        EventID: 1102  # Security log cleared
```

## Credential Access

### T1003.001 - LSASS Memory

**Description**: Credential dumping from LSASS memory

**Detection Pattern**:
```yaml
detection:
    selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess:
            - '0x1010'
            - '0x1410'
            - '0x147a'
```

### T1558.003 - Kerberoasting

**Description**: Service principal name abuse for credential theft

**Detection Pattern**:
```yaml
detection:
    selection:
        EventID: 4769
        ServiceName|endswith: '$'
        TicketEncryptionType: '0x17'
```

## Discovery

### T1087 - Account Discovery

**Description**: Adversaries enumerate account information

**Detection Pattern**:
```yaml
detection:
    selection:
        Image|endswith:
            - '\net.exe'
            - '\net1.exe'
        CommandLine|contains:
            - 'user'
            - 'group'
            - 'localgroup administrators'
```

### T1082 - System Information Discovery

**Description**: System and hardware information gathering

**Detection Pattern**:
```yaml
detection:
    selection:
        Image|endswith:
            - '\systeminfo.exe'
            - '\wmic.exe'
        CommandLine|contains:
            - 'os get'
            - 'computersystem'
```

## Lateral Movement

### T1021.001 - Remote Desktop Protocol

**Description**: Remote access via RDP

**Log Sources**: network_connection, authentication

**Detection Pattern**:
```yaml
detection:
    selection:
        EventID: 4624
        LogonType: 10  # RemoteInteractive
```

### T1021.002 - SMB/Windows Admin Shares

**Description**: Lateral movement via SMB

**Detection Pattern**:
```yaml
detection:
    selection:
        EventID: 5140
        ShareName|endswith:
            - 'ADMIN$'
            - 'C$'
            - 'IPC$'
```

## Collection

### T1560 - Archive Collected Data

**Description**: Data archiving before exfiltration

**Detection Pattern**:
```yaml
detection:
    selection:
        Image|endswith:
            - '\rar.exe'
            - '\7z.exe'
        CommandLine|contains:
            - ' a '  # Add to archive
            - '-p'   # Password
```

## Command and Control

### T1071.001 - Web Protocols

**Description**: C2 over HTTP/HTTPS

**Log Sources**: network_connection, proxy

**Detection Pattern**:
```yaml
detection:
    selection:
        DestinationPort:
            - 80
            - 443
        Initiated: 'true'
    filter:
        DestinationIp|startswith:
            - '10.'
            - '172.16.'
            - '192.168.'
    condition: selection and not filter
```

## Exfiltration

### T1041 - Exfiltration Over C2 Channel

**Description**: Data exfiltration via existing C2

**Detection Pattern**:
```yaml
detection:
    selection:
        Initiated: 'true'
        DestinationPort:
            - 4444
            - 8080
            - 8443
```

## Impact

### T1486 - Data Encrypted for Impact

**Description**: Ransomware encryption activity

**Detection Pattern**:
```yaml
detection:
    selection:
        Image|endswith: '.exe'
        TargetFilename|endswith:
            - '.encrypted'
            - '.locked'
            - '.crypto'
    condition: selection
```

## Tag Format

When tagging rules with MITRE ATT&CK, use this format:

```yaml
tags:
    - attack.{tactic}           # Lowercase tactic name
    - attack.{technique_id}     # Technique ID (T####) or sub-technique (T####.###)
```

**Example**:
```yaml
tags:
    - attack.execution
    - attack.t1059.001
    - attack.defense_evasion
    - attack.t1027
```

## Multiple Techniques

Rules can map to multiple tactics and techniques:

```yaml
tags:
    - attack.execution          # Primary tactic
    - attack.t1059.001         # PowerShell
    - attack.defense_evasion   # Secondary tactic
    - attack.t1027             # Obfuscation
    - attack.t1140             # Deobfuscate/Decode Files
```

## Resources

- [MITRE ATT&CK Framework](https://attack.mitre.org/)
- [ATT&CK Navigator](https://mitre-attack.github.io/attack-navigator/)
- [Sigma ATT&CK Correlation](https://github.com/SigmaHQ/sigma/wiki/Tags)

```

### references/compliance-mappings.md

```markdown
# Compliance Framework Mappings for Sigma Detection Rules

## PCI-DSS v3.2.1

### Requirement 10.2 - Implement automated audit trails

#### 10.2.1 - Access to cardholder data

**Detection Requirements**: Monitor all access to cardholder data environments

**Sigma Tags**: `pci-dss.10.2.1`

**Example Rules**:
- File access to cardholder data locations
- Database queries accessing payment card fields
- Application logs showing cardholder data retrieval

```yaml
tags:
    - pci-dss.10.2.1
logsource:
    category: file_event
detection:
    selection:
        TargetFilename|contains: '\cardholder-data\'
```

#### 10.2.2 - All actions taken by any individual with root or administrative privileges

**Sigma Tags**: `pci-dss.10.2.2`

**Example Rules**:
- Privileged account usage
- sudo/runas commands
- Administrative actions on critical systems

```yaml
tags:
    - pci-dss.10.2.2
logsource:
    category: process_creation
detection:
    selection:
        User|contains: 'admin'
```

#### 10.2.4 - Invalid logical access attempts

**Sigma Tags**: `pci-dss.10.2.4`

**Example Rules**:
- Failed authentication attempts
- Account lockouts
- Access denied events

```yaml
tags:
    - pci-dss.10.2.4
logsource:
    category: authentication
detection:
    selection:
        EventID: 4625  # Failed logon
```

#### 10.2.5 - Use of identification and authentication mechanisms

**Sigma Tags**: `pci-dss.10.2.5`

**Example Rules**:
- Account creation/deletion/modification
- Password changes
- Multi-factor authentication events

```yaml
tags:
    - pci-dss.10.2.5
logsource:
    category: authentication
detection:
    selection:
        EventID:
            - 4720  # Account created
            - 4724  # Password reset
```

#### 10.2.7 - Creation and deletion of system-level objects

**Sigma Tags**: `pci-dss.10.2.7`

**Example Rules**:
- System service creation
- Scheduled task creation
- New user account creation

```yaml
tags:
    - pci-dss.10.2.7
logsource:
    category: process_creation
detection:
    selection:
        Image|endswith: '\sc.exe'
        CommandLine|contains: 'create'
```

## NIST SP 800-53 Rev. 5

### AU-2 - Event Logging

**Controls**: Organization defines auditable events

**Sigma Tags**: `nist-800-53.au-2`

**Coverage**:
- Security-relevant events
- Success and failure of events
- Actions by privileged users

### AU-3 - Content of Audit Records

**Controls**: Audit records contain sufficient information

**Sigma Tags**: `nist-800-53.au-3`

**Required Fields**:
- Event type, date/time, outcome
- Subject identity, object identity
- Data source

### AU-6 - Audit Review, Analysis, and Reporting

**Controls**: Review and analyze audit records

**Sigma Tags**: `nist-800-53.au-6`

**Detection Focus**:
- Automated scanning for anomalies
- Correlation of audit records
- Investigation and reporting

### AU-12 - Audit Generation

**Controls**: System provides audit record generation

**Sigma Tags**: `nist-800-53.au-12`

**Coverage**:
- Generate audit records for defined events
- Allow authorized users to select auditable events
- Privileged commands

### SI-4 - System Monitoring

**Controls**: Monitor the system to detect attacks and indicators

**Sigma Tags**: `nist-800-53.si-4`

**Detection Coverage**:
- Unauthorized access attempts
- Unauthorized use of privileges
- Malicious code detection

```yaml
tags:
    - nist-800-53.si-4
    - nist-800-53.au-12
logsource:
    category: process_creation
detection:
    selection:
        CommandLine|contains: 'mimikatz'
```

### AC-2 - Account Management

**Controls**: Account creation, modification, removal

**Sigma Tags**: `nist-800-53.ac-2`

**Example Rules**:
- Account lifecycle events
- Privileged account monitoring
- Account attribute changes

### IA-2 - Identification and Authentication

**Controls**: Uniquely identify and authenticate users

**Sigma Tags**: `nist-800-53.ia-2`

**Example Rules**:
- Multi-factor authentication
- Authentication failures
- Session management

## ISO/IEC 27001:2013

### A.12.4.1 - Event logging

**Control**: Event logs recording user activities, exceptions, and security events

**Sigma Tags**: `iso27001.a.12.4.1`

**Requirements**:
- User IDs
- System activities
- Date, time, and details of key events
- Device identity or location
- Records of successful and rejected system access attempts

```yaml
tags:
    - iso27001.a.12.4.1
logsource:
    category: authentication
detection:
    selection:
        EventID:
            - 4624  # Successful logon
            - 4625  # Failed logon
```

### A.12.4.2 - Protection of log information

**Control**: Logging facilities and log information protected

**Sigma Tags**: `iso27001.a.12.4.2`

**Detection Focus**:
- Unauthorized access to logs
- Log deletion or modification
- Log integrity violations

### A.12.4.3 - Administrator and operator logs

**Control**: System administrator and operator activities logged

**Sigma Tags**: `iso27001.a.12.4.3`

**Example Rules**:
- Privileged command execution
- System configuration changes
- Administrative access

```yaml
tags:
    - iso27001.a.12.4.3
logsource:
    category: process_creation
detection:
    selection:
        User|contains:
            - 'admin'
            - 'root'
```

### A.9.2.1 - User registration and de-registration

**Control**: Account management processes

**Sigma Tags**: `iso27001.a.9.2.1`

**Example Rules**:
- Account creation
- Account deletion
- Account modification

### A.9.4.1 - Information access restriction

**Control**: Access to information and systems restricted

**Sigma Tags**: `iso27001.a.9.4.1`

**Detection Focus**:
- Unauthorized access attempts
- Privilege escalation
- Access control violations

## SOC 2 Trust Service Criteria

### CC6.1 - Logical and Physical Access Controls

**Criteria**: Restrict access to authorized users

**Detection Coverage**:
- Authentication monitoring
- Authorization violations
- Privileged access usage

### CC7.2 - System Monitoring

**Criteria**: Monitor system components

**Detection Coverage**:
- Security event monitoring
- Anomaly detection
- Threat detection

### CC7.3 - Evaluation and Response

**Criteria**: Evaluate events and respond

**Detection Focus**:
- Security incident detection
- Alert generation and escalation
- Response actions

## Tag Format

Use this format for compliance tags:

```yaml
tags:
    - {framework}.{control-id}
```

**Examples**:
```yaml
tags:
    - pci-dss.10.2.5
    - nist-800-53.au-2
    - iso27001.a.12.4.1
```

## Multi-Framework Mapping

Rules can map to multiple frameworks:

```yaml
title: Failed Authentication Monitoring
tags:
    - attack.credential_access
    - attack.t1110
    - pci-dss.10.2.4
    - pci-dss.10.2.5
    - nist-800-53.au-2
    - nist-800-53.au-12
    - nist-800-53.ia-2
    - iso27001.a.12.4.1
    - iso27001.a.9.2.1
```

## Compliance Coverage Analysis

Use `compliance_coverage.py` script to analyze rule coverage:

```bash
# Analyze PCI-DSS coverage
python scripts/compliance_coverage.py --directory rules/ --framework pci-dss

# Generate coverage report
python scripts/compliance_coverage.py --directory rules/ --framework nist-800-53 --report coverage.md
```

## Resources

- [PCI DSS v3.2.1](https://www.pcisecuritystandards.org/)
- [NIST SP 800-53 Rev. 5](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)
- [ISO/IEC 27001:2013](https://www.iso.org/standard/54534.html)
- [SOC 2 Trust Service Criteria](https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/trust-services-criteria)

```

### references/backend-support.md

```markdown
# Sigma Backend Support Reference

## Supported SIEM/Security Platforms

### Splunk

**Backend**: `splunk`

**Query Language**: SPL (Search Processing Language)

**Installation**:
```bash
pip install pysigma-backend-splunk
```

**Conversion Example**:
```bash
python scripts/sigma_convert.py rule.yml --backend splunk
```

**Output Format**:
```spl
index=windows EventID=4688 Image="*\\powershell.exe" CommandLine IN ("*-enc*", "*-EncodedCommand*", "*FromBase64String*")
```

**Deployment**:
- Save as saved search via Splunk Web UI
- Deploy via REST API: `/servicesNS/-/-/saved/searches`
- Use Splunk Enterprise Security correlation rules

**Field Mappings**:
- Sigma `Image` → Splunk `Image` (Sysmon)
- Sigma `CommandLine` → Splunk `CommandLine`
- Sigma `User` → Splunk `User`

### Elasticsearch

**Backend**: `elasticsearch` or `elastic`

**Query Language**: Elasticsearch Query DSL / Lucene

**Installation**:
```bash
pip install pysigma-backend-elasticsearch
```

**Conversion Example**:
```bash
python scripts/sigma_convert.py rule.yml --backend elasticsearch
```

**Output Format**:
```json
{
  "query": {
    "bool": {
      "must": [
        {"wildcard": {"Image": "*\\powershell.exe"}},
        {"terms": {"CommandLine": ["-enc", "-EncodedCommand"]}}
      ]
    }
  }
}
```

**Deployment**:
- Elastic Security Detection Rules
- Kibana Saved Searches
- ElastAlert rules

**Field Mappings** (ECS - Elastic Common Schema):
- Sigma `Image` → ECS `process.executable`
- Sigma `CommandLine` → ECS `process.command_line`
- Sigma `User` → ECS `user.name`

### Microsoft Sentinel (Azure Sentinel)

**Backend**: `sentinel` or `kusto`

**Query Language**: KQL (Kusto Query Language)

**Installation**:
```bash
pip install pysigma-backend-microsoft365defender
```

**Conversion Example**:
```bash
python scripts/sigma_convert.py rule.yml --backend sentinel
```

**Output Format**:
```kql
SecurityEvent
| where EventID == 4688
| where ProcessName endswith "\\powershell.exe"
| where CommandLine contains "-enc" or CommandLine contains "-EncodedCommand"
```

**Deployment**:
- Azure Sentinel Analytics Rules
- Deploy via ARM templates
- Use Azure Sentinel API

**Field Mappings**:
- Sigma `Image` → Sentinel `ProcessName`
- Sigma `CommandLine` → Sentinel `CommandLine`
- Sigma `User` → Sentinel `AccountName`

### IBM QRadar

**Backend**: `qradar` or `aql`

**Query Language**: AQL (Ariel Query Language)

**Installation**:
```bash
pip install pysigma-backend-qradar
```

**Conversion Example**:
```bash
python scripts/sigma_convert.py rule.yml --backend qradar
```

**Output Format**:
```sql
SELECT * FROM events WHERE LOGSOURCETYPENAME(devicetype) = 'Microsoft Windows Security Event Log'
AND "EventID" = '4688'
AND "Image" ILIKE '%\\powershell.exe'
```

**Deployment**:
- QRadar Custom Rules
- Deploy via QRadar API
- AQL searches

### Elastic Security (EQL)

**Backend**: `eql`

**Query Language**: EQL (Event Query Language)

**Conversion Example**:
```bash
python scripts/sigma_convert.py rule.yml --backend eql
```

**Output Format**:
```eql
process where process.name == "powershell.exe" and
  (process.command_line like~ "*-enc*" or
   process.command_line like~ "*-EncodedCommand*")
```

**Deployment**:
- Elastic Security Detection Rules
- EQL searches in Kibana

### Chronicle (Google)

**Backend**: `chronicle`

**Query Language**: YARA-L

**Conversion Example**:
```bash
python scripts/sigma_convert.py rule.yml --backend chronicle
```

### Others

Additional backends available via pySigma plugins:

- **LimaCharlie**: EDR platform
- **OpenSearch**: Fork of Elasticsearch
- **LogPoint**: SIEM platform
- **ArcSight**: SIEM platform
- **Carbon Black**: EDR platform
- **CrowdStrike**: EDR platform (Falcon)
- **SentinelOne**: EDR platform
- **Datadog**: Cloud monitoring platform
- **Sumo Logic**: Cloud SIEM

## Backend Installation

### Core pySigma

```bash
pip install pysigma
```

### Backend Plugins

```bash
# Splunk
pip install pysigma-backend-splunk

# Elasticsearch
pip install pysigma-backend-elasticsearch

# Microsoft 365 Defender / Sentinel
pip install pysigma-backend-microsoft365defender

# QRadar
pip install pysigma-backend-qradar

# Multiple backends
pip install pysigma-backend-splunk pysigma-backend-elasticsearch
```

## Backend Limitations

### Field Mapping Gaps

Some backends may not support all Sigma field modifiers:

**Issue**: Backend doesn't support regex field modifier `|re`

**Solution**:
- Use alternative field modifiers (`contains`, `endswith`)
- Implement custom pipeline transformations
- Post-process in SIEM after conversion

### Unsupported Features

| Feature | Splunk | Elasticsearch | Sentinel | QRadar |
|---------|--------|---------------|----------|--------|
| Regex | ✓ | ✓ | ✓ | ✓ |
| Base64 decode | Limited | Limited | ✓ | Limited |
| CIDR matching | ✓ | ✓ | ✓ | ✓ |
| Wildcards | ✓ | ✓ | ✓ | ✓ |

### Data Source Availability

Not all log sources may be available in all backends:

**Check availability**:
1. Verify log source is ingested in your SIEM
2. Confirm field mappings match
3. Test converted query with sample data

## Custom Pipelines

pySigma supports custom processing pipelines for field transformations:

```python
from sigma.pipelines.sysmon import sysmon_pipeline
from sigma.backends.splunk import SplunkBackend

# Apply Sysmon field mappings before conversion
backend = SplunkBackend()
pipeline = sysmon_pipeline()
converted = backend.convert_rule(rule, pipeline)
```

## Deployment Automation

### Splunk Deployment

```python
import requests

# Splunk REST API
url = "https://splunk:8089/servicesNS/nobody/search/saved/searches"
auth = ("admin", "password")

data = {
    "name": "Sigma - Suspicious PowerShell",
    "search": converted_query,
    "description": rule.description,
    "cron_schedule": "*/5 * * * *",  # Every 5 minutes
    "actions": "email",
    "action.email.to": "[email protected]"
}

response = requests.post(url, auth=auth, data=data, verify=False)
```

### Elasticsearch Deployment

```python
from elasticsearch import Elasticsearch

es = Elasticsearch(["https://elasticsearch:9200"])

# Deploy as Elasticsearch detection rule
rule_doc = {
    "name": rule.title,
    "description": rule.description,
    "query": converted_query,
    "severity": rule.level,
    "tags": rule.tags
}

es.index(index="detection-rules", document=rule_doc)
```

### Microsoft Sentinel Deployment

```bash
# ARM template deployment
az sentinel alert-rule create \
  --resource-group myResourceGroup \
  --workspace-name mySentinelWorkspace \
  --rule-name "Sigma - Suspicious PowerShell" \
  --query "$converted_query" \
  --severity Medium \
  --enabled true
```

## Testing Converted Queries

### Splunk

```spl
# Test in Splunk search
index=windows earliest=-24h
| eval match=case(
    Image="*\\powershell.exe" AND (CommandLine LIKE "%enc%" OR CommandLine LIKE "%EncodedCommand%"), "MATCH",
    1=1, "NO MATCH"
  )
| stats count by match
```

### Elasticsearch

```json
POST /winlogbeat-*/_search
{
  "query": {
    "bool": {
      "must": [
        {"wildcard": {"process.executable": "*\\powershell.exe"}},
        {"terms": {"process.command_line": ["-enc", "-EncodedCommand"]}}
      ]
    }
  }
}
```

### Sentinel

```kql
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4688
| where ProcessName endswith "\\powershell.exe"
| summarize count() by bin(TimeGenerated, 1h)
```

## Troubleshooting

### Conversion Fails

**Error**: `Unsupported field modifier for backend`

**Solution**:
```bash
# Use debug mode to see detailed error
python scripts/sigma_convert.py rule.yml --backend splunk --debug
```

Check `references/field-modifiers.md` for backend compatibility.

### Query Doesn't Return Expected Results

**Steps**:
1. Verify log source is ingested
2. Check field name mappings
3. Test with known-positive sample
4. Validate field value case sensitivity
5. Check time range in query

### Performance Issues

Large, complex queries may impact SIEM performance:

**Optimization**:
- Add index/sourcetype filters early
- Use specific time ranges
- Optimize field modifiers (prefer exact match over regex)
- Test query performance before deployment

## Resources

- [pySigma Documentation](https://github.com/SigmaHQ/pySigma)
- [pySigma Backend Plugins](https://github.com/SigmaHQ/pySigma/blob/main/Backends.md)
- [Sigma Converter Web Tool](https://sigconverter.io/)
- [Sigma GitHub Repository](https://github.com/SigmaHQ/sigma)

```

### references/log-source-guide.md

```markdown
# Sigma Log Source Reference

## Log Source Categories

### process_creation

**Description**: Process creation/execution events

**Common Products**: Windows (Sysmon Event ID 1), Linux (auditd), EDR platforms

**Key Fields**:
- `Image` - Full path to executable
- `CommandLine` - Full command line with arguments
- `ParentImage` - Parent process executable path
- `ParentCommandLine` - Parent process command line
- `User` - User account that created process
- `IntegrityLevel` - Process integrity level (Windows)
- `Hashes` - File hashes (MD5, SHA256)

**Example**:
```yaml
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\powershell.exe'
        CommandLine|contains: '-enc'
```

### network_connection

**Description**: Network connection events

**Common Products**: Sysmon Event ID 3, Firewall logs, EDR

**Key Fields**:
- `Image` - Process making connection
- `DestinationIp` - Remote IP address
- `DestinationPort` - Remote port
- `DestinationHostname` - Remote hostname
- `SourceIp` - Local IP address
- `SourcePort` - Local port
- `Initiated` - Connection initiated (true/false)

**Example**:
```yaml
logsource:
    category: network_connection
    product: windows
detection:
    selection:
        Initiated: 'true'
        DestinationPort: 4444
```

### file_event

**Description**: File creation, modification, deletion

**Common Products**: Sysmon Events 11/23, File integrity monitoring

**Key Fields**:
- `Image` - Process creating/modifying file
- `TargetFilename` - File path
- `CreationUtcTime` - File creation time

**Example**:
```yaml
logsource:
    category: file_event
    product: windows
detection:
    selection:
        TargetFilename|contains: '\Windows\Temp\'
        TargetFilename|endswith: '.exe'
```

### registry_event

**Description**: Registry key/value modifications

**Common Products**: Sysmon Events 12/13/14, Windows Event Logs

**Key Fields**:
- `TargetObject` - Registry key path
- `Details` - Registry value data
- `EventType` - SetValue, CreateKey, DeleteKey

**Example**:
```yaml
logsource:
    category: registry_event
    product: windows
detection:
    selection:
        TargetObject|contains: '\CurrentVersion\Run'
```

### image_load

**Description**: DLL/image load events

**Common Products**: Sysmon Event ID 7

**Key Fields**:
- `Image` - Process loading the image
- `ImageLoaded` - Path to loaded DLL/image
- `Signed` - Digital signature status

**Example**:
```yaml
logsource:
    category: image_load
    product: windows
detection:
    selection:
        ImageLoaded|endswith: '\evil.dll'
        Signed: 'false'
```

### dns_query

**Description**: DNS query events

**Common Products**: Sysmon Event ID 22, DNS server logs, proxy logs

**Key Fields**:
- `QueryName` - DNS name queried
- `QueryResults` - DNS response IPs
- `Image` - Process making query

**Example**:
```yaml
logsource:
    category: dns_query
    product: windows
detection:
    selection:
        QueryName|endswith: '.onion'
```

### web_request

**Description**: HTTP/HTTPS requests

**Common Products**: Proxy logs, web server logs, WAF

**Key Fields**:
- `c-uri` - Requested URI
- `c-useragent` - User agent string
- `cs-method` - HTTP method
- `sc-status` - HTTP status code

### authentication

**Description**: Authentication events (success/failure)

**Common Products**: Windows Security Events 4624/4625, Linux auth.log

**Key Fields**:
- `EventID` - 4624 (success), 4625 (failure), 4768 (Kerberos)
- `LogonType` - Type of logon (2=Interactive, 3=Network, 10=RemoteInteractive)
- `TargetUserName` - Account being authenticated
- `WorkstationName` - Source workstation
- `IpAddress` - Source IP

**Example**:
```yaml
logsource:
    category: authentication
    product: windows
detection:
    selection:
        EventID: 4625  # Failed logon
```

## Products

Common product values:

- `windows` - Windows OS
- `linux` - Linux OS
- `macos` - macOS
- `azure` - Microsoft Azure
- `aws` - Amazon Web Services
- `gcp` - Google Cloud Platform
- `m365` - Microsoft 365
- `okta` - Okta identity platform
- `firewall` - Generic firewall
- `proxy` - Web proxy

## Service Definitions

For cloud services, use service field:

```yaml
logsource:
    product: azure
    service: azuread
```

Common services:
- `azuread` - Azure Active Directory
- `azureactivity` - Azure Activity Logs
- `cloudtrail` - AWS CloudTrail
- `cloudwatch` - AWS CloudWatch
- `gcp.audit` - GCP Audit Logs

## Field Naming Conventions

Sigma uses normalized field names:

### Process Fields
- `Image` - Full executable path
- `CommandLine` - Command line arguments
- `ParentImage` - Parent process path
- `User` - Username
- `ProcessId` - Process ID

### Network Fields
- `SourceIp` / `DestinationIp`
- `SourcePort` / `DestinationPort`
- `Protocol` - Network protocol

### File Fields
- `TargetFilename` - File path
- `SourceFilename` - Original file location (for copies/moves)

### Registry Fields
- `TargetObject` - Registry key path
- `Details` - Registry value data

## Backend-Specific Mappings

Each backend maps these generic fields to product-specific field names:

**Sigma Generic** → **Splunk Sysmon**:
- `Image` → `Image`
- `CommandLine` → `CommandLine`
- `ParentImage` → `ParentImage`

**Sigma Generic** → **Elasticsearch ECS**:
- `Image` → `process.executable`
- `CommandLine` → `process.command_line`
- `ParentImage` → `process.parent.executable`

## Log Source Discovery

To identify available log sources:

1. **Review SIEM data sources**: Check what logs are ingested
2. **Verify field mappings**: Ensure Sigma fields map correctly
3. **Test conversions**: Convert sample rules and validate output
4. **Check coverage**: Ensure critical log sources are available

## Resources

- [Sigma Log Sources](https://github.com/SigmaHQ/sigma/wiki/Log-Sources)
- [Sysmon Event IDs](https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon)
- [Windows Security Events](https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/)

```

### references/field-modifiers.md

```markdown
# Sigma Field Modifiers Reference

## Overview

Field modifiers transform field values during rule matching. Use pipe `|` syntax to apply modifiers to field names.

**Syntax**: `FieldName|modifier: value`

## String Modifiers

### contains

**Description**: Case-insensitive substring match

**Usage**:
```yaml
detection:
    selection:
        CommandLine|contains: 'powershell'
```

**Matches**:
- `C:\Windows\System32\WindowsPowerShell\powershell.exe -enc`
- `powershell -command "iex"`
- `POWERSHELL.EXE`

**Backend Support**: All backends

### startswith

**Description**: Case-insensitive prefix match

**Usage**:
```yaml
detection:
    selection:
        CommandLine|startswith: 'powershell'
```

**Matches**:
- `powershell -enc AAAA`
- `PowerShell.exe -command`

**Does Not Match**:
- `C:\Windows\System32\powershell.exe`

**Backend Support**: All backends

### endswith

**Description**: Case-insensitive suffix match

**Usage**:
```yaml
detection:
    selection:
        Image|endswith: '\powershell.exe'
```

**Matches**:
- `C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe`
- `powershell.exe`

**Backend Support**: All backends

### all

**Description**: All values in list must match

**Usage**:
```yaml
detection:
    selection:
        CommandLine|contains|all:
            - 'powershell'
            - '-enc'
            - 'FromBase64'
```

**Requires**: All three substrings present in CommandLine

**Backend Support**: Most backends (check specific backend documentation)

## Regular Expression Modifiers

### re

**Description**: Regular expression match

**Usage**:
```yaml
detection:
    selection:
        CommandLine|re: 'powershell(.exe)?\s+-enc.*'
```

**Matches**:
- `powershell -enc AAAABBBB`
- `powershell.exe -encodedcommand AAAA`

**Backend Support**: Varies by backend (Splunk ✓, Elasticsearch ✓, Sentinel ✓)

**Performance Note**: Regex can be slow on large datasets

### re (with case-insensitive flag)

**Usage**:
```yaml
detection:
    selection:
        CommandLine|re: '(?i)powershell.*-enc'
```

## Encoding Modifiers

### base64

**Description**: Match base64-encoded value

**Usage**:
```yaml
detection:
    selection:
        CommandLine|base64|contains: 'Invoke-Mimikatz'
```

**How it works**: Encodes search string to base64 before matching

**Encoded Value**: `SW52b2tlLU1pbWlrYXR6`

**Backend Support**: Limited (check backend documentation)

### base64offset

**Description**: Match base64 with offset variations

**Usage**:
```yaml
detection:
    selection:
        CommandLine|base64offset|contains: 'Invoke-Mimikatz'
```

**Why**: Base64 encoding can vary based on string position. This checks all offset variations.

**Generates**:
- `SW52b2tlLU1pbWlrYXR6`
- `ludm9rZS1NaW1pa2F0e`
- `JbnZva2UtTWltaWthdH`

**Backend Support**: Limited

### wide

**Description**: Match UTF-16 wide character encoding

**Usage**:
```yaml
detection:
    selection:
        FileContent|wide|contains: 'malicious'
```

**Encoded**: `m\x00a\x00l\x00i\x00c\x00i\x00o\x00u\x00s\x00`

## Case Modifiers

### (default - case insensitive)

**Description**: By default, Sigma matches are case-insensitive

**Usage**:
```yaml
detection:
    selection:
        CommandLine|contains: 'powershell'  # Matches PowerShell, POWERSHELL, etc.
```

## Type Conversion Modifiers

### lt / lte / gt / gte

**Description**: Numeric comparison (less than, less/equal, greater than, greater/equal)

**Usage**:
```yaml
detection:
    selection:
        EventID|gte: 4624
        EventID|lte: 4634
```

**Backend Support**: Most backends

## Aggregation Modifiers (in condition)

### count

**Description**: Count occurrences

**Usage**:
```yaml
detection:
    selection:
        EventID: 4625  # Failed logon
    condition: selection | count(TargetUserName) by SourceIp > 5
```

**Meaning**: More than 5 failed logons from same IP within timeframe

**Backend Support**: Varies (typically requires SIEM correlation capabilities)

### near

**Description**: Events occur within proximity

**Usage**:
```yaml
condition: selection1 and selection2 | near(timespan=30s)
```

**Meaning**: Both events occur within 30 seconds

**Backend Support**: Limited (backend-dependent)

## Chaining Modifiers

Modifiers can be chained:

```yaml
detection:
    selection:
        CommandLine|base64offset|contains: 'Invoke-Mimikatz'
        Image|endswith: '\powershell.exe'
```

**Order matters**: Apply modifiers left to right

**Example**: `|base64|contains` first encodes to base64, then checks contains

## Common Patterns

### Pattern 1: Flexible PowerShell Detection

```yaml
detection:
    selection:
        Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'
        CommandLine|contains:
            - '-enc'
            - '-EncodedCommand'
            - '-e '
```

### Pattern 2: Process Chain Detection

```yaml
detection:
    selection:
        ParentImage|endswith: '\winword.exe'
        Image|endswith:
            - '\powershell.exe'
            - '\cmd.exe'
            - '\wscript.exe'
```

### Pattern 3: File Path Detection

```yaml
detection:
    selection:
        TargetFilename|contains: '\AppData\Roaming\'
        TargetFilename|endswith:
            - '.exe'
            - '.dll'
            - '.ps1'
```

### Pattern 4: Encoded Command Detection

```yaml
detection:
    selection:
        CommandLine|base64offset|contains:
            - 'Invoke-Expression'
            - 'IEX'
            - 'Net.WebClient'
```

## Backend Compatibility Matrix

| Modifier | Splunk | Elasticsearch | Sentinel | QRadar |
|----------|--------|---------------|----------|--------|
| contains | ✓ | ✓ | ✓ | ✓ |
| startswith | ✓ | ✓ | ✓ | ✓ |
| endswith | ✓ | ✓ | ✓ | ✓ |
| all | ✓ | ✓ | ✓ | Partial |
| re | ✓ | ✓ | ✓ | ✓ |
| base64 | Limited | Limited | ✓ | Limited |
| base64offset | Limited | Limited | Limited | No |
| wide | Limited | Limited | Limited | No |
| lt/gt/lte/gte | ✓ | ✓ | ✓ | ✓ |

**Legend**:
- ✓: Full support
- Limited: Partial support, may require workarounds
- No: Not supported

## Best Practices

### 1. Prefer Specific Modifiers

❌ **Don't**:
```yaml
CommandLine|contains: 'powershell'
```

✓ **Do**:
```yaml
Image|endswith: '\powershell.exe'
```

**Why**: More precise, better performance

### 2. Use `all` for Multiple Requirements

❌ **Don't**:
```yaml
CommandLine|contains: 'powershell'
CommandLine|contains: '-enc'
```

✓ **Do**:
```yaml
CommandLine|contains|all:
    - 'powershell'
    - '-enc'
```

**Why**: Clearer intent, single field evaluation

### 3. Avoid Excessive Regex

❌ **Don't**:
```yaml
CommandLine|re: '.*powershell.*-enc.*'
```

✓ **Do**:
```yaml
CommandLine|contains|all:
    - 'powershell'
    - '-enc'
```

**Why**: Regex is slower, harder to tune

### 4. Test Modifiers with Backend

Always test converted queries in target SIEM:

```bash
# Convert rule
python scripts/sigma_convert.py rule.yml --backend splunk

# Test in Splunk search interface
# Verify expected matches/non-matches
```

### 5. Document Complex Modifiers

When using `base64offset` or `wide`, document why:

```yaml
title: Encoded PowerShell Command Detection
description: |
  Detects base64-encoded PowerShell commands with offset variations
  to catch encoding attempts regardless of string position.
detection:
    selection:
        CommandLine|base64offset|contains: 'Invoke-Mimikatz'
```

## Troubleshooting

### Modifier Not Supported in Backend

**Error**: `Field modifier 'base64offset' not supported by backend 'qradar'`

**Solutions**:
1. Use alternative modifier (`contains` instead of `base64offset`)
2. Implement custom pipeline transformation
3. Post-process in SIEM after ingestion

### No Matches Despite Known Positive Data

**Causes**:
- Case sensitivity (shouldn't be issue with Sigma, but check backend)
- Field name mismatch (check field mappings)
- Modifier not applied correctly

**Debug**:
```bash
# Check converted query
python scripts/sigma_convert.py rule.yml --backend splunk --debug

# Test simplified query without modifiers
# Add modifiers incrementally
```

### Performance Issues

**Problem**: Query with `|re` too slow

**Solution**:
- Replace regex with `contains`, `startswith`, `endswith`
- Add more specific filters (EventID, Image path)
- Limit time range

## Resources

- [Sigma Specification - Modifiers](https://github.com/SigmaHQ/sigma-specification/blob/main/Sigma_specification.md#field-modifiers)
- [pySigma Transformations](https://github.com/SigmaHQ/pySigma)
- [Regex Testing Tool](https://regex101.com/)

```