Builds vendor-agnostic detection rules using the Sigma rule format for threat detection across SIEM platforms including Splunk, Elastic, and Microsoft Sentinel. Use when creating portable detection logic from threat intelligence, mapping rules to MITRE ATT&CK techniques, or converting community Sigma rules into platform-specific queries using sigmac or pySigma backends.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
building-detection-rules-with-sigma
description
Builds vendor-agnostic detection rules using the Sigma rule format for threat detection across SIEM platforms including Splunk, Elastic, and Microsoft Sentinel. Use when creating portable detection logic from threat intelligence, mapping rules to MITRE ATT&CK techniques, or converting community Sigma rules into platform-specific queries using sigmac or pySigma backends.
["Execution Isolation","Process Termination","Hardware-based Process Isolation","Web Session Access Mediation","Process Suspension"]
nist_csf
["DE.CM-01","DE.AE-02","RS.MA-01","DE.AE-06"]
Building Detection Rules with Sigma
When to Use
Use this skill when:
SOC engineers need to create detection rules portable across multiple SIEM platforms
Threat intelligence reports describe TTPs requiring new detection coverage
Existing vendor-specific rules need standardization into a shareable format
The team adopts Sigma as a detection-as-code standard in CI/CD pipelines
Do not use for real-time streaming detection (Sigma is for batch/scheduled searches) or when the target SIEM has native detection features that Sigma cannot express (e.g., Splunk RBA risk scoring).
Common Misconfigurations & Verification
Logsource/field-mapping mismatch: the rule's logsource (category: process_access, product: windows) only maps to real fields when the matching pipeline runs. Converting with SplunkBackend() and no splunk_windows_pipeline() emits raw Sigma field names (TargetImage, GrantedAccess) that don't exist in your Sysmon sourcetype, so the search runs but never matches. Always pair the backend with the pipeline and diff the output fields against your actual data.
Category vs index gap:category: process_creation assumes Sysmon EventCode 1 (or 4688 with command-line auditing enabled). If the host only ships Security 4688 without Audit Process Creation + command-line capture, CommandLine-based selections silently fail — verify the source data has the fields the rule keys on.
Backend conversion drift: the same rule yields different operators per backend (|contains → *0x1010* wildcards in SPL but a match in EQL). A rule that tests clean in Splunk can over/under-match in Elastic. Convert and unit-test against each target, don't assume portability.
Filter logic inversion:condition: selection and not 1 of filter_* makes broad |endswith: '\svchost.exe' filters swallow true positives (malware named svchost.exe in a non-system path). Anchor filters on full path/signature, not basename.
Verification: run sigma check for syntax, fire a known-true event (e.g., mimikatz LSASS access) to confirm 4/4 test cases match, then run a 7-day non-alerting backtest to measure the FP rate before promoting to a correlation/analytics rule.
Prerequisites
Python 3.8+ with pySigma and appropriate backend (pySigma-backend-splunk, pySigma-backend-elasticsearch, pySigma-backend-microsoft365defender)
from sigma.rule import SigmaRule
from sigma.validators.core import SigmaValidator
rule = SigmaRule.from_yaml(open("rule.yml").read())
validator = SigmaValidator()
issues = validator.validate_rule(rule)
for issue in issues:
print(f"{issue.severity}: {issue.message}")
Step 3: Convert to Target SIEM Query
Convert to Splunk SPL:
from sigma.rule import SigmaRule
from sigma.backends.splunk import SplunkBackend
from sigma.pipelines.splunk import splunk_windows_pipeline
pipeline = splunk_windows_pipeline()
backend = SplunkBackend(pipeline)
rule = SigmaRule.from_yaml(open("rule.yml").read())
splunk_query = backend.convert_rule(rule)
print(splunk_query[0])
Output:
TargetImage="*\\lsass.exe" (GrantedAccess="*0x1010*" OR GrantedAccess="*0x1038*"
OR GrantedAccess="*0x1fffff*" OR GrantedAccess="*0x40*")
NOT (SourceImage="*\\svchost.exe") NOT (SourceImage="*\\csrss.exe")
NOT (SourceImage="*\\wininit.exe")
Convert to Elastic Query (Lucene):
from sigma.backends.elasticsearch import LuceneBackend
from sigma.pipelines.elasticsearch import ecs_windows_pipeline
pipeline = ecs_windows_pipeline()
backend = LuceneBackend(pipeline)
elastic_query = backend.convert_rule(rule)
print(elastic_query[0])
Track detection coverage using the ATT&CK Navigator:
import json
# Generate ATT&CK Navigator layer from Sigma rules
layer = {
"name": "SOC Detection Coverage",
"versions": {"attack": "14", "navigator": "4.9", "layer": "4.5"},
"domain": "enterprise-attack",
"techniques": []
}
# Parse Sigma rules directory for technique tagsimport os
from sigma.rule import SigmaRule
for root, dirs, files in os.walk("sigma/rules/windows/"):
for f in files:
if f.endswith(".yml"):
rule = SigmaRule.from_yaml(open(os.path.join(root, f)).read())
for tag in rule.tags:
ifstr(tag).startswith("attack.t"):
technique_id = str(tag).replace("attack.", "").upper()
layer["techniques"].append({
"techniqueID": technique_id,
"color": "#31a354",
"score": 1
})
withopen("coverage_layer.json", "w") as f:
json.dump(layer, f, indent=2)
Step 5: Test Rule Against Sample Data
Create test data and validate the rule catches the expected events:
# Use sigma test framework
sigma test rule.yml --target splunk --pipeline splunk_windows
# Or manually test in Splunk with sample data# Upload Sysmon process_access log with known Mimikatz signature
Validate false positive rate by running against 7 days of production data in a non-alerting saved search.
Step 6: Deploy to Production SIEM
Deploy the converted query as a scheduled search or correlation rule:
Splunk ES Correlation Search:
| tstats summariesonly=true count from datamodel=Endpoint.Processes
where Processes.process_name="*\\lsass.exe"
by Processes.src, Processes.user, Processes.process_name, Processes.parent_process_name
| `drop_dm_object_name(Processes)`
| where count > 0
Elastic Security Rule (TOML format):
[rule]name = "LSASS Memory Access - Credential Dumping"description = "Detects suspicious access to LSASS process memory"risk_score = 73severity = "high"type = "eql"query = '''
process where event.action == "access" and
process.name == "lsass.exe" and
not process.executable : ("*\\svchost.exe", "*\\csrss.exe")
'''[rule.threat]framework = "MITRE ATT&CK"[[rule.threat.technique]]id = "T1003"name = "OS Credential Dumping"
