5.3 Detection Rule Engineering and Sigma Rules

Detection Engineering Paradigms: Atomic, Behavioral, and Composite

Detection engineering is the discipline of designing, implementing, and maintaining automated logic that identifies malicious adversary activity within digital environments. To build robust defenses, engineers categorize detections across three fundamental paradigms based on the David Bianco Pyramid of Pain:

1. Atomic Detection: Targets discrete indicators such as file hashes, IP addresses, domain names, or mutex strings. Hashes remain tied to a byte sequence, but indicator meaning and infrastructure ownership can change.
   • Operational Characteristics: Exact matching is often inexpensive and precise when the indicator is well sourced, but durability is limited; adversaries can recompile malware, rotate infrastructure, or alter a byte. False positives and performance still depend on indicator quality, field selection, data volume, and implementation.
2. Behavioral Detection: Focuses on adversary Tactics, Techniques, and Procedures (TTPs) and the systemic artifacts left by tool execution. Detections target patterns such as living-off-the-land binaries (LOLBins), abnormal parent-child process relationships (e.g., cmd.exe or powershell.exe spawned by w3wp.exe or WINWORD.EXE), memory injection APIs (CreateRemoteThread, VirtualAllocEx), or registry persistence mechanisms.
   • Operational Characteristics: High durability. Adversaries cannot easily alter their fundamental operating system interactions without completely re-engineering their attack tools.
3. Composite Multi-Source Correlation: Chains events across disparate security layers (e.g., correlating an external phishing email delivery with an endpoint macro execution, an encoded PowerShell command, an LSASS memory access, and an outbound HTTPS beacon to an unrecognized external IP).
   • Operational Characteristics: Maximizes detection fidelity for sophisticated multi-stage intrusions while significantly reducing single-event false positives.

---

Correlation Rule Typologies: Mechanisms and Trade-Offs

Modern SIEM engines utilize multiple correlation algorithms, each suited for distinct threat scenarios:

---

Sigma: The Open Detection Standard for SIEMs

Historically, detection engineering was fragmented by proprietary vendor lock-in. A detection written for Splunk Search Processing Language (SPL) could not run in Microsoft Sentinel (KQL), Elastic (EQL/KQL), or IBM QRadar (AQL). In 2017, security researchers Florian Roth and Thomas Patzke introduced Sigma—an open-source, vendor-agnostic signature format for log events, functioning as the log equivalent of Snort for network traffic and YARA for malicious files.

Structure of a Production-Grade Sigma Rule

A valid Sigma rule is authored in standard YAML and enforces a strict structural taxonomy:

• Metadata Block: Contains organizational tracking details including title, id (a unique RFC 4122 UUIDv4), status (experimental, test, stable), description, references, author, and date.
• Logsource Block: Defines the schema context where the telemetry resides:
  • category: The functional log class (e.g., process_creation, network_connection, file_event).
  • product: The underlying platform (e.g., windows, linux, azure, aws).
  • service: The specific subsystem or logging agent (e.g., sysmon, security, auditd).
• Detection Block: Contains the search identifiers, value modifiers, and boolean condition logic:
  • Search Identifiers: Named maps defining field-value pairs (e.g., selection, filter).
  • Value Modifiers: Transform matching behavior, such as |contains, |endswith, |startswith, |re (regular expression), |all, or |base64offset.
  • Condition: The final boolean expression linking identifiers (e.g., selection and not 1 of filter_*).
• False Positives Block: Explicitly documents legitimate administrative activities that may trigger the rule.
• Level Block: Classifies alert severity (informational, low, medium, high, critical).
• Tags Block: Maps the detection directly to external taxonomies, primarily MITRE ATT&CK technique IDs (e.g., attack.t1003.001, attack.credential_access).

---

Real-World Implementation: LSASS Memory Dumping Detection

Adversaries dump the memory of the Local Security Authority Subsystem Service (LSASS) process to harvest plaintext credentials, Kerberos tickets, and NTLM password hashes (MITRE ATT&CK T1003.001). When tools like Mimikatz or procdump.exe access lsass.exe, they request specific memory access rights (such as PROCESS_VM_READ or PROCESS_QUERY_INFORMATION). Enhanced logging via Sysmon Event ID 10 (ProcessAccess) captures these interactions.

1. The Vendor-Agnostic Sigma Rule (YAML)

title: LSASS Process Access and Memory Dumping Attempt
id: 9a244a2a-e886-4f4d-b924-f7a69bc92f18
status: stable
description: Detects suspicious process access requests to lsass.exe containing sensitive access masks typical of credential dumping utilities (e.g., Mimikatz, Taskmgr dump, procdump).
references:
  - https://attack.mitre.org/techniques/T1003/001/
  - https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
author: SOC Detection Engineering Team
date: 2026/09/05
modified: 2026/09/05
tags:
  - attack.credential_access
  - attack.t1003.001
logsource:
  category: process_access
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 10
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x0010'    # PROCESS_VM_READ
      - '0x1010'    # PROCESS_QUERY_LIMITED_INFORMATION | PROCESS_VM_READ
      - '0x1F0FFF'  # PROCESS_ALL_ACCESS
      - '0x1410'    # PROCESS_QUERY_INFORMATION | PROCESS_VM_READ
  filter_legitimate:
    SourceImage|endswith:
      - '\MsMpEng.exe'       # Microsoft Defender Antivirus
      - '\csagent.exe'       # CrowdStrike Falcon Agent
      - '\vmtoolsd.exe'      # VMware Tools Daemon
  condition: selection and not filter_legitimate
falsepositives:
  - Legitimate antivirus, EDR agents, or system diagnostics utilities inspecting process integrity.
level: high

2. Compiled Splunk Search Processing Language (SPL)

Using the pySigma compiler with the Splunk backend (sigma convert -t splunk), the rule compiles into native Splunk SPL:

index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=10 
TargetImage="*\\lsass.exe" (GrantedAccess="*0x0010*" OR GrantedAccess="*0x1010*" OR GrantedAccess="*0x1F0FFF*" OR GrantedAccess="*0x1410*") 
NOT (SourceImage IN ("*\\MsMpEng.exe", "*\\csagent.exe", "*\\vmtoolsd.exe")) 
| stats count min(_time) as first_seen max(_time) as last_seen by Computer, SourceImage, TargetImage, GrantedAccess, CallTrace 
| where count > 0

3. Compiled Microsoft Sentinel Kusto Query Language (KQL)

Using the Microsoft Sentinel backend (sigma convert -t kusto), the rule compiles into native KQL:

SysmonEvent
| where EventID == 10
| extend TargetImage = tostring(EventData.TargetImage),
         SourceImage = tostring(EventData.SourceImage),
         GrantedAccess = tostring(EventData.GrantedAccess),
         CallTrace = tostring(EventData.CallTrace)
| where TargetImage endswith @"\lsass.exe"
| where GrantedAccess has_any ("0x0010", "0x1010", "0x1F0FFF", "0x1410")
| where not(SourceImage has_any (@"\MsMpEng.exe", @"\csagent.exe", @"\vmtoolsd.exe"))
| project TimeGenerated, Computer, SourceImage, TargetImage, GrantedAccess, CallTrace

---

Using Generative AI to Draft SIEM Rules Safely

Generative AI can accelerate rule development, but it is a drafting and review aid, not a trusted detection authority. This differs from UEBA or anomaly-detection models that score live events: here, a language model helps an engineer translate an approved use-case specification into candidate Sigma, SPL, KQL, or another query language. The engineer remains accountable for data authorization, syntax, semantics, tests, deployment, and monitoring.

Give the Model a Bounded Rule Contract

A useful request supplies sanitized, non-secret context rather than raw production evidence:

1. Threat objective and scope: the behavior to detect, relevant ATT&CK technique, protected assets, and conditions that are explicitly out of scope.
2. Authoritative schema: exact table or logsource, field names and types, normalized values, timestamp semantics, and examples of representative synthetic events.
3. Detection constraints: correlation keys, time window, minimum count, case sensitivity, null handling, allowlisted administrative patterns, and performance limits.
4. Expected output: rule syntax, plain-language logic, assumptions, required data sources, unit-test cases, and likely false positives.

For example, an engineer might request a draft KQL rule for a successful Entra sign-in occurring after ten failures for the same user and source IP within fifteen minutes. The prompt should name SigninLogs, state that ResultType is handled as a string in that workspace, define which failures are in scope, and require separate positive and negative synthetic test cases. Without those details, a model may invent fields, mix Splunk and KQL syntax, use an expensive unbounded join, or turn an illustrative threshold into an unsupported universal standard.

Validate Before Production

Treat the generated rule like untrusted code:

• Schema and syntax validation: confirm every table, field, operator, escape sequence, and function against the deployed platform and sample events.
• Semantic validation: confirm the query detects the intended behavior rather than merely matching a tool name or benign administrative action.
• Positive, negative, and edge tests: test expected attacks, ordinary activity, null/missing fields, clock boundaries, duplicate events, reordered ingestion, case variation, and known administrative workflows.
• Historical backtest and cost review: measure result volume, false positives, scan size, execution time, state growth, and join cardinality over representative data.
• Peer approval and staged deployment: version the prompt, model/output metadata, final human edits, tests, and reviewer decision; deploy first in audit-only or limited scope where the platform supports it.
• Post-deployment monitoring: track precision, recall proxies, data-source health, rule errors, and drift. Roll back or retune through normal change control.

Security and Governance Failure Modes

Production logs can contain credentials, personal data, customer content, and adversary-controlled strings. Sending them to an unapproved model can violate privacy, residency, evidence-handling, and vendor-contract requirements. An attacker may also place prompt-like content in a log field; the workflow must treat log data as quoted data, not instructions. Use an approved service and data boundary, minimize and sanitize inputs, enforce retention policy, restrict connectors and tool execution, and never allow a model-generated query or response action to auto-deploy merely because it parses.

Language models can hallucinate event IDs, fields, ATT&CK mappings, API behavior, or performance claims. They can also produce plausible rules that silently omit a branch, mishandle operator precedence, or overfit the examples. Retrieval from current vendor schemas can reduce these errors but does not remove the need for human review and empirical tests. The defensible outcome is a traceable rule package—not an unaudited model answer.

---

Version Control and CI/CD for Detection Rules (Detection as Code)

Modern SOC detection engineering teams discard manual web-console query authoring in favor of Detection as Code (DaC). DaC treats detection signatures with the same rigor, testing, and lifecycle management applied to production software engineering:

[Detection Engineer Authors Sigma YAML]
       │
       ▼
[Git Pull Request (Branch: feature/detect-lsass-dump)]
       │
       ▼
[Automated CI/CD Pipeline (GitHub Actions / GitLab CI)]
  ├── Step 1: Linter & Schema Validation (`sigma-cli check`)
  ├── Step 2: Unit Testing against Synthetic Mock Events
  └── Step 3: Automated Compilation to Native Syntax (SPL / KQL)
       │
       ▼
[Peer Review & SOC Lead Approval -> Merge to `main`]
       │
       ▼
[Continuous Deployment (CD) via SIEM REST APIs]
  ├── Microsoft Sentinel: ARM Template / REST API update
  └── Splunk Enterprise: Saved Searches REST API payload push

The Operational Benefits of Detection as Code

1. Full Version Control & Auditability: Every rule change, tuning modification, and whitelist adjustment is tracked in Git with author attribution and timestamped commit messages.
2. Automated Syntax and Logic Testing: Continuous Integration (CI) runners execute linters (sigma-cli check) and test rules against synthetic JSON event datasets, blocking pull requests that contain invalid regex, missing fields, or syntax errors.
3. Frictionless Multi-SIEM Portability: If an enterprise migrates between SIEM platforms (e.g., migrating from on-premises Splunk to Microsoft Sentinel), the centralized Sigma Git repository can be recompiled across the new syntax backend in minutes, preserving years of engineering investment.