Xpack RBAC vs Kibana Instances/Spaces vs SIEM

[stefws (Steffen Winther Sørensen)]

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?

TIA

[TimV (Tim Vernum)]

@stefws

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’?

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

@stefws

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?

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.

@stefws

Could we possible create a role filter which picked one or more values for the 'granted document query' say from a ldap realm?

Yes, see DLS query templates.

[stefws (Steffen Winther Sørensen)]

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?

@stefws

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 (or some other source be it an elastic index, an SQL table, flat file all mapping auth user name to tenant ID(s) to filter documents by)?

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?