Detection rules
Describe the behaviour to catch in one sentence and get a Kibana detection rule (KQL / EQL / threshold) mapped to MITRE ATT&CK; export .ndjson and import into Kibana. Paid.
Paid capability, Standard (14-day trial included) and above.
Describe the intent
Three inputs:
- Index: where the rule will run. The model reads that index's actual fields (the same scan as the Field dictionary) and writes the rule with the names the cluster has.
- Intent: name the trigger, the time window and the field names, e.g. "the same source.ip produces 5 or more event.action="login_failure" within 5 minutes".
- Rule type: auto / KQL query / EQL sequence / threshold. "Auto" lets the model choose: single-condition → KQL, ordered multi-event → EQL, counting → threshold.
Arriving from an investigation report's "turn into a rule" or from Smart query pre-fills the form.
The generated rule
| Block | Content |
|---|---|
| Confidence | The model's self-assessment of how well the rule captures the intent |
| Tags | MITRE ATT&CK technique IDs and tactics |
| Query | The KQL or EQL; threshold rules also show the field and count |
| Explanation | What the rule catches, why it is written this way, likely false-positive sources |
| Full rule JSON | The Kibana rule object: name, description, severity, risk score, schedule |
Generation consults the Runbooks knowledge base ("used N runbook documents").
If the intent is too vague the model declines and says what is missing (trigger, window or field names).
Deploying to Kibana
Two routes:
- Export .ndjson: Kibana → Security → Rules → Import.
- By hand: Kibana → Security → Rules → Create rule, pick the type, paste the query / threshold configuration.
Exported rules are enabled: false. Simulate in the Detection Engine, check the false-positive rate, have operations review, then enable by hand.
Rule library
"Save as rule" stores the rule in the team library, visible to everyone; load it back, export again or delete. The library lives in .rst_copilot_userstate in ES.