Detection rule writer · free AI skill

Generates production-ready SIEM detection logic from a described threat scenario, including the detection rule in the target platform's syntax (Panther Python, Sigma, or KQL), tuning guidance to suppress false…

Purpose

Translate a described threat scenario into a deployable detection rule — complete with tuning logic, test cases, ATT&CK mapping, and a triage runbook — so detection engineers ship reliable coverage instead of starting from a blank rule file. Focused on edge and network telemetry (firewall, proxy, DNS, VPN, load balancer, CDN, and flow logs) where noisy signal makes precision hard.

When to Use

Invoke this skill when the user asks to:

Write a detection rule for a specific attack technique or threat behavior
Convert a described incident or red team finding into detection logic
Build a Panther, Sigma, or KQL rule from a log source and threat scenario
Detect suspicious activity in firewall, proxy, DNS, VPN, or network flow logs
Reduce false positives on an existing detection or tighten its tuning
Create test cases and a triage runbook for a new detection

Inputs Required

Before starting, collect:

Threat scenario: Plain-language description of the behavior to detect (e.g., "beaconing to a rare external destination on a fixed interval")
Target SIEM/platform: Panther (Python), Sigma, Splunk SPL, Elastic KQL/EQL, or Microsoft Sentinel KQL
Log source / telemetry: The specific edge or network log type (firewall, Zscaler/Squid proxy, DNS, VPN, CloudFront/CDN, VPC/NetFlow, load balancer)
Sample event schema: A field list or example log record — field names, types, nesting
Environment context: Known-benign patterns to expect (scanners, health checks, backup jobs, SaaS integrations)
Severity/priority target: Desired alert severity and rough acceptable volume (e.g., "high, <5/day")
Existing coverage: Any related rules already deployed, to avoid duplication

If the sample schema is missing, use the canonical field names for the named log source and note the assumption clearly at the top of the output.

Instructions

Step 1: Deconstruct the Threat Scenario

Break the described behavior into detectable components:

Actor action: What the attacker does (connect, resolve, exfiltrate, authenticate)
Observable artifact: What lands in the logs (destination IP, domain, port, bytes, user agent, response code)
Distinguishing signal: What separates malicious from benign (rarity, volume, timing, sequence, reputation)
Detection strategy: Choose one — signature match, threshold/aggregation, rarity/first-seen, sequence/correlation, or statistical outlier State which strategy you're using and why the chosen artifact is the most reliable, least-evadable pivot.

Step 2: Map Available Telemetry to the Signal

Confirm the log source actually contains the fields needed. For edge/network sources, anchor to these field families:

Firewall/flow: src_ip, dst_ip, dst_port, protocol, action (allow/deny), bytes_sent, bytes_received, session_duration
Proxy: url, host, http_method, user_agent, status_code, category, bytes, referer
DNS: query_name, query_type, response_code, answers, is_nxdomain, query_length, entropy
VPN/auth: username, src_geo, auth_result, session_start, device_id If a required field is absent, propose the closest available proxy field and flag the reduced fidelity.

Step 3: Write the Detection Rule

Produce the rule in the target platform's native syntax, correct and runnable:

Panther: A complete rule(event) Python function with a RULE_ID, SEVERITY, deduplication key (dedup), and a title() function returning a dynamic alert title. Include helper logic for thresholds or allowlists.
Sigma: Valid YAML with title, logsource, detection (selection + condition), falsepositives, level, and tags.
KQL/SPL/EQL: A complete query with the correct table/index, filters, aggregation, and a threshold clause. Inline-comment the non-obvious logic. Never leave placeholder field names — use the confirmed schema fields.

Step 4: Build Tuning and Allowlisting Logic

Address false positives before they happen:

Identify the top 3 likely benign sources for this signal in an enterprise network
Add explicit allowlist logic (a maintainable list of known-good domains/IPs/user agents/service accounts, referenced by variable, not hardcoded inline)
Set thresholds with a stated rationale (e.g., "beacon detection requires ≥10 connections at <5% interval jitter over 1 hour")
Recommend a suppression/dedup window to prevent alert storms from a single event burst

Step 5: Generate Test Cases

Provide at least 4 test events as structured records matching the schema:

2 true positives: Events that must fire the rule (include one edge-of-threshold case)
2 true negatives: Realistic benign events that must NOT fire (include one that looks superficially similar to the attack) State the expected result for each and the specific field value that determines it.

Step 6: Map to MITRE ATT&CK

Assign the relevant tactic and technique ID (e.g., T1071.004 — Application Layer Protocol: DNS). If it maps to multiple techniques, list the primary and secondary. Note any known evasions of this detection and what complementary rule would close the gap.

Step 7: Write the Triage Runbook

A short analyst playbook for when the alert fires:

First check: The single most important field/pivot to look at
Enrichment: What to pull (threat intel on the IP/domain, asset owner, user history)
Escalate if: Concrete conditions that confirm a true positive
Close as benign if: Concrete conditions indicating a false positive
Containment: The first response action if confirmed malicious

Output Format

Structure: Sequential sections following the steps; rule presented in a fenced code block in the correct language
Length: 700–1,100 words plus the code block
Format: Structured document with headers; rule and test events as code blocks; runbook as a labeled list
Sections: Detection Strategy → Telemetry Mapping → Detection Rule (code) → Tuning & Allowlisting → Test Cases → ATT&CK Mapping → Triage Runbook
Tone: Detection engineer to detection engineer — precise, syntax-accurate, opinionated about signal quality and evasion

Quality Checklist

Before delivering output, verify:

[ ] The rule is syntactically valid for the named platform and runnable without edits
[ ] Every field referenced in the rule exists in the provided or canonical schema — no placeholders
[ ] At least 4 test cases are present (2 fire, 2 do not) with expected results stated
[ ] Allowlist logic is variable-referenced and maintainable, not hardcoded inline
[ ] Every threshold has a stated numeric rationale, not an arbitrary value
[ ] A valid MITRE ATT&CK technique ID is assigned and correct for the behavior

Notes

Edge/network telemetry is high-volume and low-context — rarity and threshold detections almost always beat signature matches here; favor them unless the artifact is a known-bad indicator
One near-miss true negative in the test cases is the most valuable case; it proves the rule discriminates rather than pattern-matches
If the scenario is too broad to detect reliably (e.g., "detect exfiltration"), narrow it to one concrete observable and note that broader coverage requires a rule set, not a single rule

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
<your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

Drag this file into a new chat, or copy and paste its contents
Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills