[Security Solution]Read User for Security able to update Alert Status

[ghost]

Describe the bug
Read User for Security able to update Alert Status

Build Details

Version: 8.1.0-BC3
Commit:0335dd6a26ef29ae9021d0fae9347dc88f3b7d6e
Build:50346

Pre-Condition

• Create a 8.1.0 BC3 Released Build
• Create Custom User and Assign custom Role to it
• Role Configuration
  • Elasticsearch Privilege

• Kibana Privilege

Steps

• Login with above create user
• Attach the Alert to Case and make sure sync should be enable in the case
• Change the case status that will update the alert status
• Observed that by above operation read user is able to update the alert status

Additional Observation

• User with Read Privilege to Case app
  • Functionality of Case get changes to read access on whole app where there is interaction of case like attach alert to case or say attach timeline to case

Expected Result
User should not able to update alert status from case with read Privilege

Screen-Cast

update-alert-status.mp4

[elasticmachine]

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

[manishgupta-qasource]

Reviewed & assigned to @MadameSheema

[elasticmachine]

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

[yctercero]

@karanbirsingh-qasource is this present in earlier releases too? Trying to figure out how all these read only issues came about or if they've all been there for a while. Thanks so much for the testing!

[ghost]

sure @yctercero we can check the issue behavior earlier releases and it is occuring on all the previous releases

Observations

Release	Issue Status	Kibana privilege
8.1.0	Issue Occurring ❌
8.0.1	Issue Occurring ❌
8.0.0	Issue Occurring ❌
7.17.0	Issue Occurring ❌
7.16.0	Issue Occurring ❌
7.15.0	Issue Occurring ❌

Please let me known if any other checkpoint to check for this issue.

thanks !!

[yctercero]

I reached out to the RAC team about this as it has to do with how they implemented this feature within cases. It looks like this behavior was documented here - #102929

This might be partly a product question. I assume that someone who is assigned read only in "Security" and all in "Cases" is meant to just be working everything having to do with cases. Not sure how affective their role would be if they can't update the alert status, but based on the Kibana privileges it doesn't make sense that they are able to update the alert status in the case.

If a user with read only in "Security" should not be able to update the alert from the case, I would just hide that feature all together.

Any feedback here @MikePaquette @jethr0null ? (not sure who is the cases PM)

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[elasticmachine]

Pinging @elastic/response-ops-cases (Feature:Cases)

[kobelb]

This is occurring because the user has write privileges to the .alerts-security.alerts-default indices. It was my understanding that we wanted to be respecting the user's Elasticsearch privileges when reading and writing the security solution alerts.

If you all would like for us to change it so that it doesn't matter whether the user has write privileges to the .alerts-security.alerts-* indices and instead use whether the user has all access to the "Security" Kibana feature to make this determination, we can do so. It'll make our code and implementations more consistent and easier to reason about going forward.

[cnasikas]

If you all would like for us to change it so that it doesn't matter whether the user has write privileges to the .alerts-security.alerts-* indices and instead use whether the user has all access to the "Security" Kibana feature to make this determination, we can do so. It'll make our code and implementations more consistent and easier to reason about going forward.

This will also come into alignment with what the Security solution does in the alerts table. If you have read permissions to Security Solution, you cannot change the status of an alert from the table (they hide the context menu item). If you have all you can. Although, I test it and the API seems to not respect the privileges when updating the status of an alert.