| name | engineer-a-detection |
| description | Turn an observed (or hypothesized) adversary behavior into a durable detection — author a Sigma/SIEM rule, map it to the MITRE ATT&CK technique it covers, and ship a false-positive tuning plan so the rule survives contact with production logs instead of dying in alert fatigue. Returns the rule, its ATT&CK mapping, test cases, and the tuning/allow-list plan. Used by `detection-and-forensics-engineer` (primary). |
Skill: engineer-a-detection
Invoked by: detection-and-forensics-engineer (primary).
When to invoke: "write a detection/Sigma rule for X"; "we keep missing Y"; "this alert is too noisy — tune it"; after a hunt finds a repeatable behavior worth alerting on.
Output: a Sigma (or SIEM-native) rule, its MITRE ATT&CK technique ID, test cases (true-positive + benign), and a tuning plan (allow-lists, thresholds, exceptions).
When to invoke
When a behavior worth alerting on is identified — from an incident, a hunt, threat intel, or a noisy existing rule that needs tuning. Detection-as-code: the output is a reviewable, version-controlled rule, not a console click.
Output
The rule file, the ATT&CK mapping, sample-log test cases proving it fires (and doesn't over-fire), and the false-positive tuning plan.
Procedure
- State the behavior precisely. What action, on what data source (process creation, auth log, DNS, cloud audit), leaves what observable? Vague behavior → vague, noisy rule.
- Map to MITRE ATT&CK first. Identify the tactic and technique/sub-technique (e.g. T1059.001 PowerShell under Execution; T1021 Remote Services under Lateral Movement). The mapping is how coverage is reasoned about later — no mapping, no rule. See
../../knowledge/detection-and-hunting-reference.md.
- Author the Sigma rule. Write in Sigma (portable across SIEMs) with
title, status, logsource, detection (selection + condition), level, and tags including the ATT&CK technique. Prefer robust selectors (behavior/TTP) over brittle ones (a single hash/IP) — climb the pyramid of pain.
- Write test cases. At least one true-positive sample log that must fire, and one benign look-alike that must not. This is the regression suite when you tune later.
- Build the tuning plan. Enumerate expected benign sources (admin tools, backup jobs, vuln scanners), the allow-list/exception strategy, thresholds, and a target false-positive rate. A rule without a tuning plan is a future muted rule.
- Set the disposition + severity hint. What should an analyst do when it fires? Link the triage skill so a firing rule flows into
../triage-and-classify-an-incident/SKILL.md.
Quick reference — Sigma skeleton
| Field | Purpose |
|---|
title / id / status | Human name, UUID, experimental→test→stable maturity |
logsource | product/category/service the rule reads (e.g. category: process_creation) |
detection | selection: field matches + a condition: boolean |
level | low / medium / high / critical — the alert weight |
tags | attack.execution, attack.t1059.001 — the ATT&CK mapping |
falsepositives | the documented benign sources (the tuning plan's seed) |
title: Suspicious PowerShell EncodedCommand
id: 6e1a...-uuid
status: experimental
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: '\powershell.exe'
CommandLine|contains: '-enc'
condition: selection
falsepositives:
- Legitimate admin automation using encoded commands (allow-list by host/user)
level: high
tags:
- attack.execution
- attack.t1059.001
Guardrails
- Every detection maps to ATT&CK and has a tuning plan — no mapping means no coverage story; no tuning plan means alert fatigue. See
../../best-practices/every-detection-maps-to-attack-and-has-a-tuning-plan.md.
- Climb the pyramid of pain — prefer TTP/behavior selectors over a single hash or IP; those are trivial for the adversary to change.
- Detection-as-code — version-controlled, reviewed, tested against sample logs; never a one-off SIEM console edit.
- Tune iteratively, don't mute — a noisy rule gets an exception, not a delete; deletion loses the coverage.
