mcp-hayabusa: Skill for Claude Code

Detection Engineering Standards

Apply these standards to every Sigma rule in custom_rules/ — when authoring a new rule, editing an existing one, or reviewing one. If a rule under review violates a standard, flag it and propose the fix rather than silently accepting it.

1. ATT&CK technique mapping is mandatory

Every rule must carry at least one attack.tXXXX or attack.tXXXX.YYY tag in its tags: list (lowercase, matching the convention _extract_technique_ids / _rules_for_technique in server.py look for). A rule with no technique tag is invisible to analyze_coverage, detection://rules/by-technique/{technique_id}, and detection://attack/techniques/{technique_id} — it exists but contributes nothing to coverage.

• Prefer the most specific sub-technique that applies (e.g. attack.t1003.001 over bare attack.t1003) — coverage assessment matches exact-or-prefix, so specificity only adds precision, never loses a match.
• Also include the tactic tag (e.g. attack.credential-access) alongside the technique tag — every existing rule in custom_rules/ follows this pattern.
• A rule may map to more than one technique (e.g. lsass_dump_via_comsvcs.yml carries both attack.t1003.001 and attack.t1218.011 for the LOLBin angle) — tag every technique the behavior genuinely maps to, not just the primary one.

Reject a rule with no attack.t* tag, or with a tag that doesn't correspond to a real ATT&CK technique ID.

2. Severity (level) must be justified

level must be exactly one of: low, medium, high, critical (these are the only values _filter_records/min_severity in server.py understand — anything else silently fails to filter correctly). Alongside the level field, the rule's description must state why that severity was chosen — tie it to attacker impact and how deterministic the detection is, not just "this seems bad":

• critical — high-confidence, high-impact technique with few/no legitimate explanations (e.g. DCSync from a non-DC principal).
• high — strong indicator of malicious activity but with a plausible, narrow false-positive path.
• medium — suspicious pattern that also occurs in legitimate/legacy use (e.g. RC4 Kerberos tickets from old service accounts).
• low — weak/noisy signal, useful mainly as corroboration with other detections.