detection-rules

# Vulnetix Detection Rules Skill ## Use when - A CVE has no patch yet and you need detection-only mitigation. - Augmenting SAST with active runtime detection (Snort/Suricata). - Feeding the SOC engineering pipeline with rule files. - Building a Nuclei scan template for an authorised target assessment. - Hardening a YARA ruleset against a newly-discovered malware family. ## Don't use for - Executing the rules — this skill writes files; the user runs the engine. - Patching the underlying issue — use `fix`. - Single-CVE enrichment — use `vulnetix_vuln` (MCP) or `vulnetix vdb vuln <id>`. ## Conventions Follows `skills/_lib/contract.md`. In short: use the `vulnetix_*` MCP tools when the agent has them and the CLI otherwise — both shape their own output, so there is no jq step any more. Independent calls go out as concurrent Bash tool calls in one message. One trailing suggestion, not a playbook. See the contract for surface selection, output style and memory writes. Pulls IDS/IPS, malware-detection, and active-scan content for a CVE. Capability-aware: only fetches rule families the user can actually use. ## Step 1: Load capabilities Read `.vulnetix/capabilities.yaml`. Capture `derived.detection_stack`. If empty, prompt: ``` No detection tooling found (snort, suricata, yara, nuclei, semgrep). I can still fetch the raw rules — proceed? ``` If the user accepts, treat the stack as `[snort, yara, nuclei]` for completeness. Otherwise abort with a one-liner pointing at install docs. ## Step 2: Fetch each available family For each family in `detection_stack`: ```bash # Snort/Suricata vulnetix vdb snort-rules get "$ARGUMENTS" -o json vulnetix vdb traffic-filters "$ARGUMENTS" -o json # YARA vulnetix vdb yara-rules get "$ARGUMENTS" -o json # Nuclei vulnetix vdb nuclei get "$ARGUMENTS" -o json ``` Skip families absent from `detection_stack` to avoid wasted API calls. ## Step 3: Save rule files (raw form) Write rule content to `.vulnetix/detection/<VULN_ID>/`: - `snort.rules` (concat of all Snort rule bodies) - `suricata.rules` (if family present) - `vuln.yar` (concat of YARA rules) - `nuclei-<id>.yaml` (one per template) Use `--format rules` / `--format yaml` against the same subcommand: ```bash vulnetix vdb snort-rules list --cve-id "$ARGUMENTS" --format rules > .vulnetix/detection/$ARGUMENTS/snort.rules vulnetix vdb yara-rules list --cve-id "$ARGUMENTS" --format rules > .vulnetix/detection/$ARGUMENTS/vuln.yar vulnetix vdb nuclei get "$ARGUMENTS" --format yaml > .vulnetix/detection/$ARGUMENTS/nuclei.yaml ``` ## Step 4: Render report For each family, list: - Rule count + highest signature severity - File path on disk - A copy-pasteable invocation hint based on installed binaries: - `snort -c snort.conf -A console` (only if `binaries.snort: true`) - `yara vuln.yar /path/to/scan` (only if `binaries.yara: true`) - `nuclei -t .vulnetix/detection/$ARGUMENTS/nuclei.yaml -u <target>` (only if `binaries.nuclei: true`) ## Step 5: Memory update Append `event: detection-rules` with counts per family to the vuln entry. ## Notes - This skill never executes rules. The user (or `exploit-test`) runs them. - Filter is honest: if YARA is missing, the YARA section is omitted from the report and from disk writes. ## Edge cases & gotchas - Each family is fetched ONLY if the binary is in `derived.detection_stack`. Override by passing `--force` if you want raw rule output regardless. - `vdb snort-rules`, `vdb yara-rules`, `vdb nuclei` accept `--format rules|yaml` for non-JSON output (the engine's native format). - Some CVEs return zero rules across all families — that means no community detection content exists, not that the skill failed. - YARA rules can have multiple hash-only matchers; if your YARA build was compiled without hash-module support, those rules fail silently. - Nuclei templates require a target URL/IP at invocation time; the skill produces the template, not the scan. - `vdb traffic-filters <id>` returns Snort-format rules tagged for Suricata compatibility — confirm Suricata accepts the rule before deploying to Suricata.