Add a tool to support detection engine developers

[cavokz]

Would be nice to have a tool based on Geneve that can help detection engine developers iterate on their works.

[cavokz]

@spong please describe your flow and how this tool could improve it.

[spong]

Of course! 🙂

So as detailed a bit over in #128 (comment), one of the most frequent and basic workflows for us on the dev side is triggering a specific Detection Rule. We'll need to do this when developing new features, debugging rules, or digging deeper into SDH's. This often needs to be done locally on the dev machine (against a local kibana/es), but support for cloud clusters would be great too as this is often the quickest way to test previous stack versions (and of course is a more accurate representation of a customer deployment). Let's go through what this might look like...

Deployment setup

Devs will usually either be running both ES (yarn es snapshot) and Kibana (yarn start) locally against Kibana source, or running Kibana locally (yarn start) and connected via CCS to an internal deployment (like the o11y test envs. If not running locally, the other use case is usually an Elastic Cloud deployment.

Current Workflow

With the above deployments, our current workflow is to either setup beats locally, configure to the specified deployment, then perform some actions that may create the necessary source events to trigger the desired rule, or to configure an agent/endpoint and then trigger within the agent env (now a bit easier with the Endpoint CLI introduced in elastic/kibana#149903).

Note that index/mapping configuration happens as part of beat, integration, and/or agent setup, so this is handled as part those steps.

Automated Workflow

Ideally, it would be great to interact with geneve or an intermediary tool that would automate the index/mapping configuration setup, and then perform an index operation for a number of documents that would trigger a specific detection rule.

At minimum, this tooling would take a Detection Rule name (Persistence via Update Orchestrator Service Hijack) or id/rule_id (58df1cf0-a643-11ed-bf5b-914b730eb325), and maybe some additional config like how many times to replay, interval, replacement variables, etc. All deployment configuration would default to local kibana/es, but could be overridden with additional flags to say point to a cloud deployment. E.g.

geneve trigger-rule "Persistence via Update Orchestrator Service Hijack"

Which would perform the following:

• Install/enable latest (since version not specified) prebuilt rule Persistence via Update Orchestrator Service Hijack (on local kibana instance)
• Fetch query from rule, and generate sample source documents
• Fetch index patterns from rule, generate mappings from source docs, push mappings as index patterns named on rule (to local es)
• Ingest source documents into indices defined on rule (to local es)
• Rule triggers on next execution 🎉

And with additional simple configuration to modify the flow:

geneve trigger-rule "Persistence via Update Orchestrator Service Hijack" --replay 5 --interval 3m --variable host.name=geneve

Which would do the same as above, but re-ingest the source documents 5 times, every 3 minutes, and replace the host.name name field with the value geneve.

And then of course some flags for choosing additional deployments:

Explicit local

geneve trigger-rule "Persistence via Update Orchestrator Service Hijack" --es http://elastic:[email protected]:9200 --kibana http://elastic:[email protected]:5601/kbn

Cloud

geneve trigger-rule "Persistence via Update Orchestrator Service Hijack" --es https://cloudy.es.europe-west1.gcp.cloud.es.io --kibana https://cloudy.kb.europe-west1.gcp.cloud.es.io:9243 --cloudID abcxyz

---

Hopefully this outlines this frequent use case from detection engineers, but let me know if you have any questions and happy to pair or expand further. Outside generating relevant source events, the mapping/index configuration is the next largest point of friction as we usually have to hunt down a specific mapping, either installing beats locally, specific endpoint integrations (that might not be easily configured), or a full agent.