[Security Solution][Detections] Supporting alerts-on-alerts Pre-packaged Rules

[spong]

The detection-rules repo is looking to start shipping Pre-packaged Rules leveraging alerts-on-alerts (AOA from here) functionality (elastic/detection-rules#1755). This will be the first time shipping AOA prebuilt rules and will require some considerations to fully support.

What are AOA Rules?

AOA Rules are not a specific rule type, but rather a rule configuration who's source index points at an alerts index (hence alerts on alerts). This functionality is often bundled with the Building Block Rules feature to allow flexibility around which tier of alerts are visible to the end user.

Considerations when using AOA with Pre-packaged Rules

1. Access control of pre-defined source index

Since the alerts index is space aware, it's not possible to pre-define the index field on an AOA rule without using wildcards, as such, there could be unintended crossover between spaces if the Rule Author has access to multiple spaces' alert indices. As a result, we may want to provide either a sentinel value, or programmatically identify when an alerts index is being used in the index field, and then when creating the rule we lock the value into whatever the alerts index is for the space the rule is being created in.

2. If specifying an index, which index to use? .alerts-* or .siem-signals-*?

Going forward (8.x+), we should reference the alerts index as .alerts-*. This will be backwards compatible for users upgrading from 7.x as their system will the necessary index/field aliases back to their 7.x .siem-signals-* indices.

3. [Add more considerations here...]

[elasticmachine]

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

[elasticmachine]

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

[banderror]

@spong thank you for this write-up! Just a few thoughts:

As a result, we may want to provide either a sentinel value, or programmatically identify when an alerts index is being used in the index field

As an alternative, we could explicitly represent a rule as being a "rule-on-alerts" in the API (via a new field) and rule creation/editing UI (e.g. via a checkbox). Similar to what we do for representing "building block" rules. Users wouldn't need to remember any special values that would indicate an alerts index for the current Kibana space.

then when creating the rule we lock the value into whatever the alerts index is for the space the rule is being created in

I think calculating and locking the value of the index on rule creation might not work well in the future with rules sharing between spaces. I'd probably suggest calculating it at runtime at the start of execution.

[spong]

As an alternative, we could explicitly represent a rule as being a "rule-on-alerts" in the API (via a new field) and rule creation/editing UI (e.g. via a checkbox). Similar to what we do for representing "building block" rules. Users wouldn't need to remember any special values that would indicate an alerts index for the current Kibana space.

Yeah, good point, a dedicated field would be ideal. I was trying to steer away from adding additional logic to our API wrapper around the Rules API, but that'll add more complexity than just adding a dedicated field. We should touch base with the @elastic/response-ops-ram folks now that they're interested in pre-packaged rules and see if this makes sense in the core alerting API.

I think calculating and locking the value of the index on rule creation might not work well in the future with rules sharing between spaces. I'd probably suggest calculating it at runtime at the start of execution.

++, thanks for the distinction! Sharing security rules between spaces feels pretty nebulous at the moment, and intricacies like this in support of it keep popping up. Do you know if there's a meta issue floating around for supporting sharing security rules that we can use to document considerations like these? (edit: I didn't see one for security, but this framework level ones: #107161, #100067, #104316) I still need to make an issue for supporting secondary static id's in the SO client (as part of), so I can make one and reference if not already captured (secondary static id support now being explored in this internal doc) .

[banderror]

Do you know if there's a meta issue floating around for supporting sharing security rules

@spong nope, not aware of any :( I can create a placeholder issue and ping Michelle. It looks like no one has really thought through this yet.