[SecuritySolution][Detections] Provide finer grained feature controls between editing rules and modifying alerts

[spong]

Currently it isn't possible to set up a Detections user such that they can update Alerts yet cannot modify Rules. The update alert status actions require canUserCRUD && hasIndexWrite permissions. Where canUserCrud is set to true when granting All to the Security app for the space, and hasIndexWrite being satisfied via the ES Index Privileges).

canUserCRUD is extracted from the Kibana application capabilities (uiCapabilities.siem.crud). Note the kibana application in code still remains siem, but is mapped to the Security application within the UI (as of 7.9.x+).

Note: it is possible to set the Saved Objects Management privilege to NONE to prevent rule creation (resulting in an error creating the exception-list-agnostic, however it is still possible to edit rules.

As a near-term fix, we could relax the canUserCrud check on the alert actions above and just rely on the signals index permissions, so you could then set the Security app permissions to READ and achieve permissions for editing alerts, but not rules, although this ends up being a little confusing since the Security app would be configured as read but allows edits. What we really need here are the finer grained kibana app privileges, and have an Update Alerts sub-item leveraging Kibana Feature Controls.

cc @MikePaquette @dhurley14

[dhurley14]

I started working on this locally and made the change on the frontend to reduce the canUserCrud privileges on the alerts action bar but got a 403 error back when I closed an alert with a t1_analyst1 role. As of this change the introduction of the refresh parameter on the updateByQuery call requires one of the following privileges [maintenance,manage,all]

My understanding of this addition was the alerts count in the detections table was not accurate when we bulk closed alerts. The solution is we either remove this refresh parameter and find another fix for that bug or we have to update the privilege requirements for our base-level role of t1_analyst to include one of [maintenance,manage,all].

cc: @MikePaquette @spong

[spong]

Thanks for the details @dhurley14! As discussed, let's move forward with the slight front-end changes to support this and understanding that the t1_analyst role will require the maintenance permissions for the .siem-signals* index as well in order to update an alert's state.

cc @jmikell821 @Donnater -- this change will require an update to the Detections pre-requisites docs here, as we'll need to call out the need for the maintenance permissions for .siem-signals* index. Honestly though, thoughts on re-organizing this page or having an additional page for detailing specific user roles and the required permissions? This would be really helpful for users to easily see what permissions they need to create common roles that would be used in SOCs like the t1_analyst role above. Thoughts?

[LeeDr]

FYI, this issue has an enhancement label and a 7.11.0 label. Since we're past FF for 7.11.0 this should move out to 7.12.0.

[spong]

Correct, thanks @LeeDr! We've got a minor fix going into 7.11 to address this for the near-term, but will keep this open as an enhancement for 7.12+. Removing version label for now until this is prioritized as part of a future effort.

[Hashtpari]

@peluja1012 can you please confirm if this ticket can be closed or is it still outstanding as some parts of it have been merged? Thank you

[yctercero]

This is still not implemented as a feature - leaving open for now