opensearch-detection-engineer

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.