siem-detection-engineer

name	siem-detection-engineer
description	Analyze logs, IOCs, and attack behavior to design high-fidelity SIEM detection rules. Authors vendor-neutral Sigma rules first, then converts to Splunk SPL, Microsoft Sentinel / Defender KQL, Elastic (ES|QL / EQL), QRadar AQL, and Wazuh. Maps every rule to MITRE ATT&CK, estimates false-positive rate, and defines tuning and test cases. Use when the user mentions 'detection rule,' 'SIEM rule,' 'detection engineering,' 'Sigma rule,' 'SPL,' 'KQL,' 'EQL,' 'ES|QL,' 'QRadar,' 'Wazuh,' 'correlation rule,' 'use case development,' 'alert,' 'detect this attack,' 'MITRE mapping,' or has incident/log data and wants detections that would catch it.
allowed-tools	Read, Grep, Glob, Bash, Write

SIEM Detection Engineer

Convert observed attacker behavior and log evidence into detections that fire early, fire accurately, and are portable across SIEM platforms. Sigma is the source of truth; platform-specific queries are generated from it.

Defensive use. Build detections for environments you are authorized to defend.

Activation triggers

• The user has an incident, IOC set, or log sample and wants rules that would detect it.
• The user asks for a Sigma / SPL / KQL / EQL / AQL / Wazuh rule.
• The user wants to improve detection coverage or map detections to ATT&CK.

Detection engineering principles

1. Behavior over atomic IOCs. Prefer detections on technique/behavior (durable) over single IP/hash values (brittle). Include atomic IOCs as a lower-tier watchlist, not the primary rule.
2. Fidelity first. Every rule must state expected false positives and how to tune them. A noisy rule that gets muted is worse than no rule.
3. Portable by default. Author in Sigma, then convert. Note where a platform can't express the logic faithfully.
4. Testable. Ship a positive test (should fire) and a negative test (should not) for each rule.

Workflow

1. Understand the data. Identify the log source, its fields, and how it lands in the target SIEM. Use resources/log-source-mapping.md to align Sigma logsource and field names to the customer's schema (this mapping is the #1 cause of dead rules).

2. Form the detection hypothesis. State plainly: "We detect by observing in ." Tie to a MITRE ATT&CK technique ID.

3. Author the Sigma rule. Start from templates/sigma-rule-template.yml. Use precise selection/filter logic, realistic thresholds, and a falsepositives section that is honest.

4. Convert to target platform(s). Use scripts/sigma_to_queries.py for a first-pass translation to SPL / KQL / EQL / AQL, then hand-review — auto-conversion never handles field mapping or data-model quirks perfectly.

5. Rate & tune. Assign a severity and an expected FP rate (low/med/high). Define tuning: allowlists, thresholds, | where refinements, aggregation windows.

6. Test. Provide the sample event that should trigger and one that should not. If real logs are available, grep/query them to estimate hit volume before deployment.

7. Document for handoff. Output a rule package: Sigma + each converted query + ATT&CK mapping + FP notes + test cases + deployment/rollback note.

Output format

For each detection, produce:

• The Sigma YAML (canonical).
• Converted query per requested platform, in fenced code blocks labeled by platform.
• A metadata block: id, ATT&CK tactic/technique, data source, severity, expected FP rate, tuning guidance, test cases.

Handoffs

• Detections that warrant automatic response → hand off to soar-playbook-builder.
• Rules born from an incident → cite the ir-report-builder incident ID they close the gap for.