Expose index connector and action in custom security detection configuration

[jethr0null]

Kibana alerting users are able to utilize the index connector and action when configuring alerts. We should explore exposing this capability when configuring custom security detections (rules).

This connector should index a document per alert (vs. a single document for all alerts generated by a rule execution).

Use cases for multi-document indexing:

• Limit data access by applying DLS security on each per signal trigger.
• Chain detection rules together (dynamic mapping is not allowed in siem signals and this is a workaround requiring individual documents)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[spong]

Created a draft PR adding this functionality (it's a 1-liner 🙂) and in testing everything seems to be functional 👍.

Only thing of note here is that it doesn't appear to be possible to index multiple documents per action firing, so a rule execution could create 100 alerts (to .siem-signals-default), yet the user would only be able to index a single document using all the data from those 100 alerts. Perhaps it's possible to wrap the action template with the mustache looping syntax (i.e. {{#context.alerts}}{{/context.alerts}}), but I wasn't able to get any variant of this to pass validation in order to save the rule and test (API validation TBD, so maybe that way?).

Without the ability to write multiple documents per action firing, I question the usefulness of this feature and if it'll just prove to be more of a headache to users expecting a larger degree of flexibility here. That said, it can at least be leveraged to write data to arbitrary indices, so more functionality/flexibility than is available today.

At this point I think it's a Product/UX decision on if we want to move forward here as-is, or include prioritization of multi-document support as part of this effort. Would need to check with @elastic/kibana-alerting-services on LOE there since they own this connector, but wouldn't imagine this to be too large of an effort, just impactful since it would most likely change the accepted format from valid JSON.

cc @jethr0null @elastic/security-design

[mikecote]

From doing a quick search, it seems correct, I don't think we have a workaround at this time other than solving the problem. The @elastic/kibana-alerting-services team is tracking such limitations under #89430.

[spong]

As mentioned in closed draft PR (#111813), will hold off on implementing until dependency #89430 is resolved and we can support indexing multiple documents per action execution context.

Got 👍 from product to add for 7.16 -- merged in #111813.