/opensearch-detection-engineer

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 con