Is it possible to use a single instance of Elastic SIEM to monitor two different companies networks and separate them so their information will be separated?
Hi @austinsonger, welcome to our community!
The Elastic SIEM/Security App does not explicitly support single-cluster multi-tenancy.
Some users have approximated this use case by using the underlying role-based-access controls of Elasticsearch and the Spaces feature of Kibana, but they take on the responsibility of ensuring that the separation between tenants is adequate to meet their requirements.
For example, they may (this is not a complete list):
- Create a Kibana Space for each tenant
- Create a set of tenant-specific indices for data ingestion
- Assign tenant-users to roles that have permissions to access only their tenant-specific indices
- Create index patterns that point to the tenant-specific indices
- Change the SIEM/Security app advanced settings in each tenant Space to point to that tenant's index patterns
- Update the detection rules in each tenant Space to point to only tenant-specific index patterns
- Note: Currently the machine-learning anomaly detection capabilities and rules do not support the Kibana Space separation, so must be disabled or handled separately.
The most secure and private approach to providing Elastic SIEM services to multiple tenants is to allocate one Elastic deployment (Elasticsearch cluster + Kibana instance) per tenant, and then use a separate deployment via Cross Cluster Search to manage the overall operation.
Can you tell us more about your use case? What level of separation are you required to provide between the two company networks you mention? Are you required to meet any regulatory requirements for data separation? Are you using an existing system to provide these multi-tenant services?
Thanks!
2 Likes
I will add that ML jobs will become "Space-aware" very soon, possibly in the 7.11 release
1 Like
Hi all,
I think it is not needed to change each detection rule for each tentant to the tenant-specific index patterns.
I played some around with the multi-tenancy options. I discovered that when you create a rule with a user which has only access to specific tentant indexes it queries (signals) only on those indeces. So:
- Create a Kibana Space for the tenant, let say 'companyA'
- Create a user with a role which has:
o Cluster privileges: manage
o Index privileges: indeces: *companyA*, privileges: all
o Kibana: for the space 'companyA' all privileges except for the ingest manager - Add to all indices names the space-id after the indices, so for beats:
‘%{[@metadata][beat]}-%{[@metadata][version]} -%{+YYYY.MM.dd}-companyA
Now log in with the tentant user and load the pre-build rules or create one. The rules will only query the indices where the rule creater has acces too.
But watch out when you log in with a superuser / administrator which has access to all indices. If you create a rule for a tentant you are the creator of the rule and so will the rule query all indices. Then it is possible that you have a signal for companyB in .siem-signals-companyA. So only add rules with a user which has only access to the tentant indices.
1 Like
Just want to point out that you have to be careful of when you enable/disable a rule and/or edit a rule that the user who touches it last becomes the owner of the rule with their permissions.
Also, if you update a users's permissions who is currently the owner of rules that user will have to disable/enable those rules one time in order to get the new permissions.
This is because at the moment under the covers an encrypted API key with the permissions is created each time the user enables/disables a rule or edits the rule and those permissions are honored even if they don't match recent permission changes until the rule is updated one way or the other.
3 Likes
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.