Xpack RBAC vs Kibana Instances/Spaces vs SIEM

Got some architectural questions concerning security.

Currently ingesting documents tagged with tenant ID fields into shared indices (winlogbeat-, auditbeat- etc.) for SIEM purposes for our SOC.

Would like to grant access individual tenants access to their specific documents only while our SOC continue to have access across all documents.

Could we create Xpack Roles with fixed tenant filters to limit document access through the ’Granted documents query’ under ‘Grant read privileges to specific documents’?

If above is possible would so a role fixed tenant filter also have the same effect in the SIEM App, so an individual tenant only would see their own documents and anormalities?

Could we possible create a role filter which picked one or more values for the 'granted document query' say from a ldap realm?
So we wouldn't have to create per tenant role, but could administer tenant attribute values to filter documents in a ldap directory?

Wondering if we just should create a Kibana Space per tenant or if it would be best for scalability to create individual Kibana instances possible with their own .kibana index... though not sharing the .kibana index properly would be an issue for ML and SIEM Timelines, right?


Yes, you can do this. This is referred to as Document Level Security in Elasticsearch.

DLS is applied at the elasticsearch level, so any product that queries from the original indices, as the logged in user, will reflect the user's document limits. This will apply in SIEM.

However, when you refer to anormalities, I presume you mean machine learning anomaly detection. That is a little trickier - ML reflects the security limits of the user that created the detection job, not the user that is viewing the anomalies themselves.
So, unless you create new anomaly detection jobs for each tenant, I don't think you will get the results you are looking for. However, perhaps one of the ML specialists might chime in with a solution.

Yes, see DLS query templates.

Thanks for your reply @TimV

Concerning ML, I understand it stores anormalities in it's own seperat indices and they will of course not be tagged with tenant IDs as the ML results are generally across all documents of selected indices traversed. ML is properly hard to virtualize/sliceNdice while preserving our SOC overall access.

Timelines are stored in .kibana index as I understand it, even though we may control retention time of ML results with results_retention_days. How can we manage TimeLines live cycles, so .kibana index doesn't just grow wild over time?

Any thoughts on the other questions?

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.