Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
elastic avatar

Security Detection Rule Management

  • 2.2k installs
  • 546 repo stars
  • Updated July 22, 2026
  • elastic/agent-skills

Elastic skill for creating and tuning SIEM and endpoint detection rules via Kibana API.

About

The security-detection-rule-management skill creates and tunes Elastic Security detection rules through the Kibana Detection Engine API via rule-manager.js. It covers noisy SIEM rule tuning, endpoint behavior exceptions, new rule creation after query validation, and alert volume investigation workflows. Prerequisites require Node.js 22+, KIBANA_URL, ELASTICSEARCH_URL, and API keys or username/password pairs. Multi-step workflows pair rule_manager find/noisy-rules with run_query investigations before patch, exception, or create actions. Endpoint rules must use fetch_endpoint_rule then add_endpoint_exception rather than manual script calls. Agents report exact rule IDs, names, alert counts, and API errors without abbreviation. Install dependencies from skills/security with npm install before first use. Invoke when false positives spike, new threat coverage is needed, or endpoint exclusions require scoped exceptions. Uses rule-manager.js against Kibana Detection Engine API. Workflows: noisy-rules, exceptions, create-after-run_query validation.

  • Uses rule-manager.js against Kibana Detection Engine API.
  • Workflows: noisy-rules, exceptions, create-after-run_query validation.
  • Requires Node 22+ and Kibana/Elasticsearch env credentials.
  • Endpoint rules use fetch_endpoint_rule plus add_endpoint_exception.
  • Reports exact rule UUIDs, alert counts, and API errors faithfully.

Security Detection Rule Management by the numbers

  • 2,179 all-time installs (skills.sh)
  • +159 installs in the week ending Aug 5, 2026 (Skillselion tracking)
  • Ranked #282 of 2,203 Security skills by installs in the Skillselion catalog
  • Security screen: HIGH risk (skills.sh audit)
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
At a glance

security-detection-rule-management capabilities & compatibility

Capabilities
rule creation · false positive tuning · endpoint exceptions · alert investigation
Works with
elasticsearch
Use cases
security audit
Pricing
Bring your own API key
From the docs

What security-detection-rule-management says it does

Create new detection rules for emerging threats and coverage gaps, and tune existing rules to reduce false positives.
SKILL.md
npx skills add https://github.com/elastic/agent-skills --skill security-detection-rule-management

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs2.2k
repo stars546
Security audit3 / 3 scanners passed
Last updatedJuly 22, 2026
Repositoryelastic/agent-skills

How do I reduce false positives or add coverage for emerging threats in Elastic Security?

Create, tune, and manage Elastic Security detection rules via Kibana Detection Engine API for SIEM and endpoint coverage gaps and false positives.

Who is it for?

SOC teams managing Elastic Security detection rules and exceptions.

Skip if: Non-Elastic SIEM platforms or generic vulnerability scanning.

When should I use this skill?

User mentions noisy rules, detection rule tuning, Kibana detection engine, or endpoint exceptions.

What you get

Tuned or new detection rules with validated queries and documented exceptions.

  • Detection rules
  • Exception lists
  • Exported rule packs

Files

SKILL.mdMarkdownGitHub ↗

Detection Rule Management

Create new detection rules for emerging threats and coverage gaps, and tune existing rules to reduce false positives. All operations use the Kibana Detection Engine API via rule-manager.js.

Execution rules

  • Start executing tools immediately — do not read SKILL.md, browse the workspace, or list files first.
  • Report tool output faithfully. Copy rule IDs, names, alert counts, exception IDs, and error messages exactly as

returned by the API. Do not abbreviate rule UUIDs, invent rule names, or round alert counts.

  • When a tool returns an error (rule not found, API failure), report the exact error — do not guess at alternatives.

Prerequisites

Install dependencies before first use from the skills/security directory:

cd skills/security && npm install

Set the required environment variables (or add them to a .env file in the workspace root):

export ELASTICSEARCH_URL="https://your-cluster.es.cloud.example.com:443"
export ELASTICSEARCH_API_KEY="your-api-key"
export KIBANA_URL="https://your-cluster.kb.cloud.example.com:443"
export KIBANA_API_KEY="your-kibana-api-key"

Common multi-step workflows

TaskTools to call (in order)
Tune noisy SIEM rulerule_manager find/noisy-rules → run_query (investigate FPs) → rule_manager patch or add-exception
Add endpoint behavior exceptionfetch_endpoint_rule (get rule definition from GitHub) → add_endpoint_exception (scoped to rule.id)
Create new detection rulerun_query (test query against data) → rule_manager create
Investigate rule alert volumerule_manager get → run_query (query alerts index)

For endpoint behavior rules, always fetch the rule definition first to understand query logic and existing exclusions before adding an exception. For SIEM rules, always investigate alert patterns with run_query before tuning.

Critical: For endpoint behavior rules, always use fetch_endpoint_rule (not shell or direct script calls) to get the rule definition, then use add_endpoint_exception to add the exception. These are dedicated tools — do not invoke the underlying scripts manually.

Workflow: Tune a rule for false positives

Steps 1–2: Identify noisy rules and analyze false positives

Find noisy rules with noisy-rules or find, then get the rule definition and investigate alerts:

node skills/security/detection-rule-management/scripts/rule-manager.js noisy-rules --days 7 --top 20
node skills/security/detection-rule-management/scripts/rule-manager.js find --filter "alert.attributes.name:*Suspicious*" --brief
node skills/security/detection-rule-management/scripts/rule-manager.js get --id <rule_uuid>
node skills/security/alert-triage/scripts/run-query.js "kibana.alert.rule.name:\"<rule_name>\"" --index ".alerts-security.alerts-*" --days 7 --full

Look for patterns: same process/user/host → exception candidate; broad pattern → tighten query; legitimate software → exception; too broad → rewrite or adjust threshold.

Step 3: Choose a tuning strategy

In order of preference:

1. Add exception — Best for specific known-good processes, users, or hosts. Does not modify the rule query. Use when the rule is correct in general but fires on known-legitimate activity.

2. Tighten the query — Patch the rule's query to exclude the FP pattern. Best when the false positives stem from the query being too broad.

3. Adjust threshold / alert suppression — For threshold rules, increase the threshold value. For any rule type, enable alert suppression to reduce duplicate alerts on the same entity.

4. Reduce risk score / severity — Downgrade the rule's priority if it generates many low-value alerts but still has some detection value.

5. Disable the rule — Last resort. Only if the rule provides no value or is completely redundant with another rule.

Steps 4–5: Apply tuning, verify, and document

Add exception (single/multi-condition, wildcard via matches):

node skills/security/detection-rule-management/scripts/rule-manager.js add-exception \
  --rule-uuid <rule_uuid> \
  --entries "process.executable:is:C:\\Program Files\\SCCM\\CcmExec.exe" "process.parent.name:is:CcmExec.exe" \
  --name "Exclude SCCM" --comment "FP: SCCM deployment" --tags "tuning:fp" "source:soc" --yes

Patch query, threshold, severity, or disable:

node skills/security/detection-rule-management/scripts/rule-manager.js patch --id <rule_uuid> --query "process.name:powershell.exe AND NOT process.parent.name:CcmExec.exe" --yes
node skills/security/detection-rule-management/scripts/rule-manager.js patch --id <rule_uuid> --max-signals 50 --yes
node skills/security/detection-rule-management/scripts/rule-manager.js patch --id <rule_uuid> --severity low --risk-score 21 --yes
node skills/security/detection-rule-management/scripts/rule-manager.js disable --id <rule_uuid> --yes

Write operations (patch, enable, disable, delete, add-exception, bulk-action) prompt for confirmation by default. Pass --yes to skip the prompt (required when called by an agent).

Verify with rule-manager.js get --id <rule_uuid>. Update triage cases via the case-management skill.

---

Workflow: Create new detection rule

Steps 1–2: Define the threat, data sources, and fields

Specify MITRE ATT&CK technique(s), required data sources (Endpoint, Network, Cloud), and malicious vs legitimate behavior. Common indexes: logs-endpoint.events.process-*, logs-endpoint.events.network-*, .alerts-security.alerts-*, logs-windows.*, logs-aws.*. Key fields: process.name, process.command_line, process.parent.name, destination.ip, winlog.event_id, event.action. Verify data with run-query.js:

node skills/security/alert-triage/scripts/run-query.js "process.name:certutil.exe" --index "logs-endpoint.events.process-*" --days 30 --size 5

Step 3: Write and test the query

Rule types: query (KQL field matching), eql (event sequences), esql (aggregations), threshold (volume-based), threat_match (IOC correlation), new_terms (first-seen). Test against Elasticsearch before creating:

node skills/security/alert-triage/scripts/run-query.js "process.name:certutil.exe AND process.command_line:(*urlcache* OR *decode*)" \
  --index "logs-endpoint.events.process-*" --days 30

For EQL, use --query-file to avoid shell escaping issues.

Validate query syntax before creating or patching a rule. The validate-query command catches common errors locally — escaped backslashes, mismatched parentheses, unbalanced quotes, and duplicate boolean operators:

node skills/security/detection-rule-management/scripts/rule-manager.js validate-query \
  --query "process.name:taskkill.exe AND process.command_line:(*chrome.exe* OR *msedge.exe*)" --language kuery

The create and patch commands also run validation automatically and reject invalid queries. Pass --skip-validation only if you are certain the query is correct despite triggering a check.

Common KQL syntax mistakes:

  • Escaped forward-slashes — KQL wildcards use plain text. Write */IM chrome.exe*, not *\/IM chrome.exe*.
  • Mismatched parentheses — every ( must have a matching ).
  • Unbalanced quotes — every " must be paired.
  • Duplicate operatorsAND AND or OR OR is always an error.

Step 4: Create the rule

node skills/security/detection-rule-management/scripts/rule-manager.js create \
  --name "Certutil URL Download or Decode" \
  --description "Detects certutil.exe used to download files or decode Base64 payloads, a common LOLBin technique." \
  --type query \
  --query "process.name:certutil.exe AND process.command_line:(*urlcache* OR *decode*)" \
  --index "logs-endpoint.events.process-*" \
  --severity medium --risk-score 47 \
  --tags "OS:Windows" "Tactic:Defense Evasion" "Tactic:Command and Control" \
  --false-positives "IT administrators using certutil for legitimate certificate operations" \
  --references "https://attack.mitre.org/techniques/T1140/" \
  --interval 5m --disabled

For complex rules (EQL sequences, MITRE mappings, alert suppression), use create --from-file rule_definition.json and --threat-file. See references/detection-api-reference.md for schema.

Step 5: Monitor and iterate

Monitor alert volume with noisy-rules --days 3 --top 10 and tune false positives as needed.

---

Workflow: Endpoint behavior rules tuning

Tune Elastic Endpoint behavior rules by adding Endpoint exceptions scoped to specific rules. Endpoint exceptions live in Security → Exceptions → Endpoint Security Exception List, not under individual SIEM rules.

Key principles: Always fetch the rule definition from protections-artifacts first. Always scope exceptions to the rule (rule.id or rule.name). Use full paths over process names. Run the mandatory entity cross-check (Step 4b) before any exception. Simulate impact (Step 5b) and aim for ≥60% noise reduction.

Scripts: fetch-endpoint-rule-from-github.js (get rule TOML by id), add-endpoint-exception.js (add to Endpoint Exception List; rule.id/rule.name required), check-exclusion-best-practices.js.

For the full step-by-step workflow (Steps 1–6), queries, and simulation templates, see references/endpoint-behavior-tuning-workflow.md. For exclusion best practices, see references/endpoint-rule-exclusion-best-practices.md.

---

Tool reference

rule-manager.js

All commands are run from the workspace root. All output is JSON unless noted.

CommandDescription
findSearch/list rules with optional KQL filter
getGet a rule by --id or --rule-id
createCreate a rule (inline flags or --from-file)
patchPatch specific fields on a rule
enableEnable a rule
disableDisable a rule
deleteDelete a rule
exportExport rules as NDJSON
bulk-actionBulk enable/disable/delete/duplicate/edit
add-exceptionAdd an exception item to a rule
list-exceptionsList items on an exception list
create-shared-listCreate a shared exception list
noisy-rulesFind noisiest rules by alert volume
validate-queryCheck query syntax before create/patch

Endpoint behavior tuning: fetch-endpoint-rule-from-github.js (get rule TOML by id), add-endpoint-exception.js (add to Endpoint Exception List; rule.id/rule.name required), check-exclusion-best-practices.js.

Exception entry format

Pass entries as field:operator:value. Operators: is, is_not, is_one_of, is_not_one_of, exists, does_not_exist, matches, does_not_match. Example: process.name:is:svchost.exe, file.path:matches:C:\\Program Files\\*.

Additional resources

  • For full API schema details, see references/detection-api-reference.md
  • For endpoint behavior tuning: references/endpoint-exceptions-guide.md,

references/endpoint-rule-exclusion-best-practices.md

  • For alert investigation during tuning, use the alert-triage skill
  • For documenting tuning actions in cases, use the case-management skill

Examples

  • "Find the noisiest detection rules from the last 7 days and help me tune one"
  • "Add an exception to exclude SCCM from the suspicious PowerShell rule"
  • "Create a new detection rule for certutil URL download or decode"

Guidelines

  • Report only tool output. When summarizing results, quote or paraphrase only what the tools returned. Do not invent

IDs, hostnames, IPs, scores, process trees, or other details not present in the tool response.

  • Preserve identifiers from the request. If the user provides specific hostnames, agent IDs, case IDs, or other

values, use those exact values in tool calls and responses — do not substitute different identifiers.

  • Confirm actions concisely. After executing a tool, confirm what was done using the tool's return data. Do not

fabricate internal IDs, metadata, or status details unless they appear in the tool response.

  • Distinguish facts from inference. If you draw conclusions beyond what the tools returned (e.g., suggesting a MITRE

technique based on observed behavior), clearly label those as your assessment rather than presenting them as tool output.

  • Start executing tools immediately. Do not read SKILL.md, browse directories, or list files before acting.
  • Report tool output verbatim. Copy rule IDs, names, alert counts, and error messages exactly as returned. Do not

abbreviate UUIDs or round numbers.

Production use

  • All write operations (create, patch, enable, disable, delete, add-exception, bulk-action,

add-endpoint-exception) prompt for confirmation. Pass --yes or -y to skip when called by an agent.

  • Endpoint exceptions suppress detections globally. Always scope exceptions to a specific rule using rule.id or

rule.name in the entries. A broad, unscoped exception can silently reduce detection coverage.

  • Verify environment variables point to the intended cluster before running any script.
  • Use --dry-run with bulk-action to preview impact before executing bulk changes.

Environment variables

VariableRequiredDescription
ELASTICSEARCH_URLYesElasticsearch URL (for noisy-rules aggregation)
ELASTICSEARCH_API_KEYYesElasticsearch API key
KIBANA_URLYesKibana URL (for rules API)
KIBANA_API_KEYYesKibana API key

Related skills

Forks & variants (1)

Security Detection Rule Management has 1 known copy in the catalog totaling 2 installs. They canonicalize to this original listing.

How it compares

Pick Security Detection Rule Management for Elastic SIEM rule API automation rather than general AWS secrets or appsec scanning skills.

FAQ

How do I tune a noisy SIEM rule?

rule_manager noisy-rules, run_query to investigate FPs, then patch or add-exception.

What env vars are required?

KIBANA_URL plus API key or username/password and matching Elasticsearch credentials.

How are endpoint exceptions added?

fetch_endpoint_rule for definition, then add_endpoint_exception scoped to rule.id.

Is Security Detection Rule Management safe to install?

skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

Securityauditappsec

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.