mcp-hayabusa: Skill for Claude Code

Detection Engineering Standards

Every Sigma rule authored or reviewed under this skill must satisfy all five standards below. Treat a rule that fails any of them as not done — do not present it as finished, and flag every violation when reviewing someone else's rule.

The five standards

1. ATT&CK technique mapping

The rule's tags: list must include at least one tag in attack.tXXXX (or attack.tXXXX.XXX for a sub-technique) format, e.g. attack.t1003.001. A rule with no technique tag has no place in the ATT&CK-indexed view of the rule set and must be rejected or sent back for mapping.

• Check: at least one tag matches ^attack\.t\d{4}(\.\d{3})?$ (case-insensitive).
• If the behavior genuinely doesn't map to a technique, that's a signal the rule may be too broad or mis-scoped — don't tag a placeholder technique just to satisfy the check.

2. Severity with justification

level: must be exactly one of: low, medium, high, critical. No other value (including Sigma's own informational) is acceptable in this project.

• The rule must also carry a short justification for why that level was chosen — put it in description: (e.g. "high: direct evidence of credential dumping via LSASS access, low benign rate") rather than leaving the level as an unexplained bare enum value.
• Reject a rule whose description doesn't explain the severity choice, even if the level: field itself is valid.

3. Documented false positive conditions

falsepositives: must be a real, specific list — not empty, not ["Unknown"], not ["None"] used as a lazy default. Each entry should describe a concrete condition or tool that would legitimately trigger the rule (e.g. "Administrative use of PsExec for patch deployment", "Backup software performing volume shadow copy operations").

• A rule claiming zero false positives needs that claim justified in the description, not just an empty list.

4. At least one test case

Every rule needs at least one accompanying test case demonstrating it fires on real or synthetic matching data. In this repo that means a sample .evtx (or exported record) under sample_evtx/ — or an equivalent fixture — plus a note (in the rule's references: or a sibling test) of what sample log/record it was validated against and what the expected match is.