mcp-hayabusa: Skill for Claude Code

Detection Engineering Standards

Enforce these standards on every Sigma/detection rule this project writes, reviews, or discusses. Apply them whether authoring a new rule, editing an existing one, or reviewing someone else's — flag any rule that doesn't meet them rather than silently passing it.

Standards checklist

1. ATT&CK technique mapping required. Every rule must include at least one attack.tXXXX tag (e.g. attack.t1059.001), lowercase, in the rule's tags: field. A rule with no ATT&CK tag is incomplete — do not approve or ship it without one, and don't invent a technique ID that doesn't fit; ask or leave it flagged if the right mapping isn't obvious.

2. Severity must be justified. The level: field must be one of low, medium, high, critical — no other values. Every rule must also carry a short justification for why that level was chosen (e.g. in the description: field or an inline comment), not just the bare level. "high because X" is required, "high" alone is not sufficient.

3. False positive conditions must be documented. Every rule must have a falsepositives: field listing realistic conditions that would cause benign activity to match (e.g. specific admin tools, scheduled tasks, software installers). An empty list, Unknown, or omitting the field is not acceptable — if you genuinely can't identify any, that itself is a red flag worth raising rather than silently accepting.

4. At least one test case is required. Every rule must be accompanied by at least one test case demonstrating it fires on the intended malicious/suspicious behavior (a sample log record, an .evtx fixture, or an equivalent documented scenario). A rule with no test case is not done.

5. Naming convention. Rule names (the title:-derived identifier / filename, not necessarily the human-readable title: string itself) must be lowercase with underscores — e.g. suspicious_powershell_encoded_command, not SuspiciousPowerShellEncodedCommand or suspicious-powershell-encoded-command.