[RAC] - Integrating RBAC with rules that query alerts indices

[yctercero]

When a user creates a rule, they are able to specify which indices they would like searched. One possible index that a user can search is the alerts indices. With RBAC a users permissions are managed through the Kibana feature privileges, which is an abstraction layer - that is, a user is not ever given explicit ES permissions, because theoretically, all calls will be going through Kibana --> ES.

In the current security solution implementation of rules/alerts, a user is granted ES level privileges for the index where alerts are stored (.siem-signals*). If a rule queries .siem-signals* we’re able to easily check permissions as we run our queries using currentUser. However, with the RBAC implementation, users no longer receive ES level privileges, so querying ES as currentUser will not work, but querying with internalUser is very risky as each index contains numerous rule type alerts all of which the user may not have permissions to. So it is not just a matter of what alert index a user can access, but what documents (alerts) within that index a user can access.

The outstanding questions would be:

• How can we allow users to create rules that query alerts indices while respecting RBAC?

[elasticmachine]

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

[gmmorris]

How can we allow users to create rules that query alerts indices while respecting RBAC?

Sounds like we'd need to pass in a scoped service, like we already for for ES and SO, which such rules can use.
It means the AlertClient (for the alerting indices) will run as the the user who created the rule.

Does that make sense @mikecote ?

[mikecote]

Is there a requirement to query alert indices + other indices?

If so, I'm not sure @gmmorris' approach will work.

[elasticmachine]

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

[yctercero]

Is there a requirement to query alert indices + other indices?

@mikecote not sure about requirements for 7.14, but it's an existing use case in security solution. I think @dhurley14 is checking to see if it's possible to do in the observability workflow right now.

[mikecote]

Thanks, @yctercero! I think the proposals and approach will vary depending on this requirement. Keep me posted 🙂

[pmuellr]

It seems like if a user wants to create alerts over alert-as-data indices, they're going to want that user to have access to the alerts-as-data indices for read access in any case. Is it reasonable to create an alert over data you can't read? Perhaps for something super-generic, like "generate an alert if there are > 3 errors executing alerts over an hour". I'd guess most of these meta-alerts will be more data-y specific than that.

So, seems to me like there's not really a problem here. The user will have to have ES privs to be able to read the indices, so they can use Discover/Dashboards, at which point they'll have enough privs to be able to run a query with an API key built from their privs in an alert.

I'm curious if a user would even "see" an alerts-as-data access they weren't given privs to; would the indices even show up in an "index picker" UI prompt?

[aarju]

We have several use cases for 'alerts on the alerts' in Infosec and an issue I ran into was that we use spaces and originally I created the alert on the index pattern .siem-signals* but then I kept seeing alerts going off but I had no idea why and I couldn't view the original alert. It turned out I was alerting on some testing rules that someone else had created in a completely different space that I didn't have access to. After I figured out what was happening I changed the index pattern to .siem-signals-spacename*. The .siem-signals* index patterns don't show up in the index picker but you can manually type them in and they work. I think a better solution would be to add the current space's signal index automatically to the picker and disallow index patterns that ignore the spaces to prevent this type of information leakage from happening.

[aarju]

For context here are some examples of 'alerts on alerts' that we use in Infosec. These are all threshold alerts

• Multiple distinct alerts on a single host. Having multiple different rules fire on a single host elevates the priority
• Multiple alerts of one type on a single host. This elevates the priority of an investigation to determine why only one host is setting off an alert so much.
• A single rule firing on more than 10 hosts in an hour. This is usually an indicator that a rule is noisy and needs to be tuned. Usually caused by a newly deployed script or application.

We also have a watcher that looks at the .kibana-events* index and alerts if a lower than expected number of rules were run which indicates that there are problems with detection engine.

[marshallmain]

Security rules continue to use the current user permissions in the RAC implementation so this issue is resolved.