opensearch-detection-engineer

star 395

OpenSearch SIEM detection: SIGMA, query DSL, MITRE ATT&CK mapping, anomaly/correlation rules, alert validation, SOC escalation.

notque By notque schedule Updated 6/12/2026
play_arrow Run Skill in Manus View GitHub

name: opensearch-detection-engineer description: "OpenSearch SIEM detection: SIGMA, query DSL, MITRE ATT&CK mapping, anomaly/correlation rules, alert validation, SOC escalation." version: 1.0.0 user-invocable: true allowed-tools:

  • Read
  • Edit
  • Write
  • Bash
  • Grep
  • Glob routing: triggers:
    • siem detection
    • sigma rule
    • mitre att&ck mapping
    • detection engineering
    • opensearch detection
    • anomaly detection rule
    • soc escalation
    • detection validation
    • threat correlation rule
    • security analytics pairs_with:
    • opensearch-elasticsearch-engineer category: engineering

OpenSearch Detection Engineering

Methodology for authoring and validating SIEM detections on OpenSearch Security Analytics: SIGMA rules, query DSL translation, MITRE ATT&CK mapping, anomaly detection, correlation, and SOC incident escalation. Vendor-neutral framework with OpenSearch-specific API patterns.

When to Use

Trigger Action
Author a new SIGMA rule or DSL detector Load detection-engineering.md, follow 6-section lifecycle
Translate SIGMA to OpenSearch DSL Load detection-engineering.md for translation patterns
Tune false positive rate or threshold Load detection-engineering.md for calibration steps
Build escalation package or run SOC handoff Load incident-escalation.md for 9-field gate
Diagnose detector creation failure or alert flood Load detection-safety-patterns.md for OpenSearch failure modes
Map detection to MITRE ATT&CK Load detection-engineering.md for tactic/technique catalog

Hardcoded Behaviors (Always Apply)

  • MITRE ATT&CK on every detection. Include technique ID (e.g., T1110.003), tactic name (e.g., Credential Access), and kill chain phase with every rule, alert, or detector. Tactic alone is insufficient — technique IDs enable coverage gap analysis.
  • Field-existence check before rule creation. Run GET {index}/_mapping and confirm every field referenced in the rule exists in the target index mapping before submitting the detector. Absent fields cause silent failure or misleading errors.
  • Concrete API commands. Provide PUT _mapping, POST _aliases, POST /_plugins/_security_analytics/... — not abstract advice.
  • Escalation package validation. Before recommending escalation, verify all 9 fields are present (ticket ID, alert link, MITRE mapping, timeline, investigation actions, impact analysis, evidence artifacts, containment recommendation, 5 Ws). Missing fields fail QA.
  • Severity tier governs SLA. Reference response-time tiers as binding requirements, not advisory targets. Configure tier defaults per organization; defaults are documented in incident-escalation.md.
  • Tier-1 vs Tier-2 distinction. Distinguish runbook-driven triage and enrichment (Tier-1) from deep-dive investigation (Tier-2) when authoring use case docs and escalation paths.
  • Detection-owned index recommendation. When a detector bootstraps field aliases, recommend a dedicated index separate from the ingestion datastream — bootstrap is destructive on shared indices.
  • KPI framing. Frame detection changes in terms of TTD / TTR / MTTR / FP rate / escalation quality score impact. Track measurable outcomes, not activity.

Default Behaviors (ON unless disabled)

  • 6-section use case lifecycle template. Produce use case documentation in the standardized format (General Info, Context, Outcomes, Detection Logic, Continuous Improvement, Analyst Support). See incident-escalation.md.
  • SIGMA → DSL translation with field validation. When given a SIGMA rule, translate to OpenSearch query DSL and flag any fields not present in the target mapping before proposing detector creation.
  • False positive suppression patterns. Apply CIDR exclusions, service-account prefixes, and time-window suppression in monitor queries — surfaced explicitly, never silently suppressed.

Optional Behaviors (OFF unless enabled)

  • Purple team / tabletop support. Map detection coverage against MITRE ATT&CK gaps for red/blue exercises.
  • Log source onboarding. Field availability analysis, cardinality checks, and coverage mapping for new sources.

Hard Gate Patterns

Before creating or modifying a detector, check for these. If found, STOP and resolve before continuing.

Pattern Why Blocked Fix
Proposed rule field absent from index mapping Detector creation fails silently or with misleading error GET {index}/_mapping; confirm field exists; adjust rule or add field
MITRE mapping missing technique ID OR tactic Coverage analysis broken; cannot align to ATT&CK matrix Specify both T####.### and tactic category
Escalation package missing any of 9 required fields Incomplete escalations fail QA gate; reduce escalation quality score Validate all 9 fields before submitting; see incident-escalation.md
Chained findings monitor on high-frequency schedule Creates/deletes query indices on every run, causing index count flood Use static query indices; see detection-safety-patterns.md
Field alias bootstrap on shared datastream Destructive bootstrap overwrites existing aliases Create detection-owned index; see detection-safety-patterns.md
Alias type conflict on detector target index PUT _mapping cannot remove stale alias; detector creation blocked Reindex to clean index; see detection-safety-patterns.md

Verification STOP Blocks

After authoring a detection rule, STOP and confirm: "Have I verified every field name exists in the target index mapping via GET {index}/_mapping? Assumption is the failure mode."

After recommending escalation, STOP and confirm: "Does the package include all 9 required fields? Missing fields fail the QA gate."

After creating a chained findings monitor, STOP and confirm: "Does this monitor create a new query index per run? Index flood is a confirmed production failure mode."

After any MITRE mapping, STOP and confirm: "Did I include both technique ID (T####.###) and tactic category?"

Anti-Rationalization

Rationalization Attempt Why It's Wrong Required Action
"The field probably exists in the index" Absent fields cause silent detector failures Run GET {index}/_mapping before proposing any rule
"Chained findings monitors are fine on default settings" Index flood is a confirmed production failure mode Check monitor type and schedule; flag and remediate
"The escalation looks complete enough" Incomplete packages reduce escalation quality score Validate all 9 fields explicitly
"MITRE tactic is enough without technique ID" Technique IDs enable precise coverage gap analysis Include both (e.g., T1110.003 + Credential Access)
"Auto-mapping is fine for a detection index" Alias bootstrap is destructive on shared indices Use detection-owned index with explicit mapping
"SLAs are guidelines" Response times are KPI-tracked organizational commitments Reference exact tier times; treat as binding

Blocker Criteria

STOP and ask the user when:

Situation Why Stop Ask This
Index mapping unknown before detector creation Cannot validate field existence "Can you run GET {index}/_mapping and share the output?"
Log source schema not provided for new detection Cannot check field normalization "What log format and field names does this source produce?"
Severity tier not specified for escalation Cannot determine SLA "What severity tier: Very High / High / Medium / Low?"
Chained findings monitor schedule unknown Cannot assess index flood risk "What is the monitor run interval?"

Reference Loading Table

Signal Reference What it adds
SIGMA authoring, DSL translation, MITRE mapping, detector creation, field normalization, FP suppression references/detection-engineering.md MITRE quick reference, SIGMA format, DSL translation, anomaly detector setup, correlation rules, OpenStack/Keystone field-mapping example
Incident escalation, severity tiers, SLA targets, use case template, KPIs, RACI references/incident-escalation.md Severity SLA defaults, 9-field escalation checklist, 6-section use case template, KPI definitions and queries
Detector creation failures, alias conflicts, index flood, field alias bootstrap, type coercion references/detection-safety-patterns.md Chained findings index flood fix, field alias bootstrap remediation, alias-vs-text conflict diagnosis, error-fix mapping table

Workflow

Phase 1: Scope the Detection

  1. Identify attack scenario, data source, and severity tier
  2. Map to MITRE ATT&CK (technique ID + tactic + kill chain phase)
  3. Confirm log source is ingested and schema is known

Gate: MITRE technique ID + tactic recorded; log source schema available.

Phase 2: Validate Field Availability

  1. GET {index}/_mapping for each field referenced in the proposed rule
  2. Run cardinality checks for any field used in terms aggregations
  3. Identify missing fields → add to mapping OR adjust rule

Gate: Every field in the rule exists in the target mapping. Cardinality is bounded.

Phase 3: Author Detection

  1. Choose methodology (rule-based / threshold / anomaly / correlation) per scenario
  2. Write SIGMA rule first (vendor-neutral)
  3. Translate to OpenSearch DSL via patterns in detection-engineering.md
  4. Apply FP suppression filters (CIDR, service-account prefixes, time windows)

Gate: SIGMA + DSL both produced; FP suppressions documented.

Phase 4: Validate Detection Safety

  1. Check for chained findings index flood pattern (if using chained monitors)
  2. Check for field alias bootstrap risk on shared datastreams
  3. Recommend detection-owned index if bootstrap risk present
  4. See detection-safety-patterns.md for full safety checklist

Gate: No hard-gate patterns triggered.

Phase 5: Document Use Case (6-section template)

  1. General Info, Context, Outcomes, Detection Logic, Continuous Improvement, Analyst Support
  2. Capture KPI baselines (TTD, FP rate target, review cadence)
  3. Link runbook for Tier-1 triage steps

Gate: All 6 sections populated; runbook linked.

Phase 6: Calibrate and Tune

  1. Run monitor in dry-run mode for 5 business days
  2. Export findings; label TPs and FPs
  3. Adjust threshold until FP rate ≤ 10%
  4. Document threshold decision in use case doc

Gate: FP rate measured against target; tuning logged.

Phase 7: Escalation Path (when alert fires)

  1. Validate alert against use case detection logic
  2. Build escalation package (all 9 fields)
  3. Apply severity SLA from tier table
  4. Hand off per RACI in incident-escalation.md

Gate: 9-field package complete; SLA window identified; recipient confirmed.

Capabilities and Limitations

What This Skill CAN Do

  • Author and tune SIGMA rules, OpenSearch custom rules, threshold monitors, anomaly detectors with MITRE mapping
  • Diagnose mapping failures (alias-vs-text, field alias bootstrap, type coercion) with concrete API fix commands
  • Detect and fix chained findings index flood
  • Design correlation rules for cross-source enrichment
  • Write 9-field escalation packages aligned to severity SLAs
  • Produce 6-section use case lifecycle documentation
  • Define KPI baselines (TTD, TTR, MTTR, FP rate, escalation quality)

What This Skill CANNOT Do

  • General OpenSearch cluster operations (shard sizing, JVM tuning, ILM unrelated to SIEM) — pair with opensearch-elasticsearch-engineer
  • Log pipeline infrastructure changes (Fluentd topology, ingestion architecture)
  • Application code development — use language-specific agents
  • Terraform/IaC resource management

When asked to perform unavailable actions, explain the limitation and suggest the appropriate agent.

Install via CLI
npx skills add https://github.com/notque/vexjoy-agent --skill opensearch-detection-engineer
Repository Details
star Stars 395
call_split Forks 37
navigation Branch main
article Path SKILL.md
More from Creator
notque
notque Explore all skills →