How to exploit rules

[georgii (Georgii Gorbachev)]

Hey @Iroshu, the way you can use placeholders in a rule action's body is documented here:

Create a detection rule | Elastic Security Solution [8.11] | Elastic

In this doc you can find a few examples, including the one showing how you can iterate over the context.alerts array that contains all detection alerts generated during a rule run.

The mustache syntax which is used in rule action bodies is suitable for generating text documents, but falls short when you need to generate valid JSON.

For example, this would be a valid text payload for sending to a webhook:

{{#context.alerts}}
Detection alert for user: {{user.name}}
{{/context.alerts}}

However, generating a JSON doc is problematic. The only easy thing you can do is string concatenation:

{
  "user_names": "{{#context.alerts}}{{user.name}}, {{/context.alerts}}"
}

Or you could index all generated alerts concatenated into a string field, which I'm not sure would be useful at all:

{
  "alerts": "{{context.alerts}}"
}

Some folks managed to workaround this problem for webhooks, you can read more here:

Elastic Rule Connector sends a String instead of JSON to the Webhook

Hey there! First of all, I'd like to describe my situation. I have an Elastic Rule, that successfully creates the Alerts in the Elastic Security. Now I have configured a connector, that allows me to send those Alerts to my custom webhook. It works, but all Alert data (in JSON format by default) is sent as a string. Then I added the Content-Type header with the value application/JSON, but nothing changed. this is a sample of what I receive at webhook when I use a JSON content-type header. [i…

However, indexing ndjson is not an option for the Index Connector, where we'd have to create a valid document. I'd imagine something like that could work:

{
  "alerts": [
    {{#context.alerts}}
      {{{.}}},
    {{/context.alerts}}
    {"last_alert": "fake_document"}
  ]
}

but the form of the index connector doesn't allow to specify non-valid JSON (related issue) and it seems you can't save a rule with a non-valid action body anymore. UPD: you can save a Webhook action with an invalid body (so you can use the workaround), but you can't do the same with an Index action - this one strictly requires the body to be valid JSON (so the workaround won't work).

FWIW one of our teams was planning to work on adding support for triggering rule actions per each generated alert separately, which might be a good option for reindexing them as is into a separate index. I'm not aware of any timeframes though.

And we prefer to avoid playing with the system index.

Unless you need additional or transformed data in your own index (meaning not the alerts as is), you should feel safe and free to read from the system .alerts-security.alerts-* index. This index is managed by the Security app and alerts are written to it by the app itself, you don't need to configure anything to enable that.

Let me know if this information was helpful or not.