Multi-tenancy with Elastic SIEM detection rules

[admlko]

Hi,

Multi-tenancy can be easily gained with ML detection rules using partition field. Just partition based on the field containing customer id.

Could this same approach be used with SIEM detection rules?
If I have understood correctly, currently the detection rules uses only index pattern and query. Maybe with some aggregation?

Thanks!

[Frank_Hassanabad]

Hi @admlko,

You can make different spaces and load the rules you want to use within the different spaces and restrict access to those spaces for your users as well as the permissions to each .siem-signals-${space_id} to the users in each of those spaces.

For the input indexes, you would do the same thing where if you have indexes that you do not want users to see you can restrict those to the same spaces those users have permissions to.

So it's flexible enough to solve these use cases but the specifics of the use cases will dictate how you decide to set these up and slight differences can lead to slightly different ways to implement it.

Refs:
https://www.elastic.co/guide/en/kibana/7.8/xpack-spaces.html#spaces-control-user-access
https://www.elastic.co/guide/en/elasticsearch/reference/7.8/security-privileges.html

[admlko]

Hi @Frank_Hassanabad,

Thank you for your reply.

I am going to use different spaces for different customers, so that would be the way to go. However, I would need to modify each rule one by one for every customer to include only their indices, correct?

Currently, all the customers have their own indices prefixed with the customer id. I am playing around with the idea of a single index for each type of log source where all customers would use the same index. Document level security would be used to dictate which documents each customer would see (basically if customer_id -field equals to the customer id).

So, in the point of maintenance burden view - what would be the way to go?

[Frank_Hassanabad]

Document level security could be helpful for sure to decrease the amount of manual labor you would have to do probably in a few interesting ways.

Otherwise, your next two best bets would be either a bit of scripting using the API where you can control how you store, load, enable, and activate your rules in any pretty much any way you want to:
https://www.elastic.co/guide/en/siem/guide/current/rules-api-update.html

...or...

You do an export of the rules which would is in ndjson format (http://ndjson.org/), ndjson format is just the rules separated as 1 json message/rule per line and then a single count in JSON format at the bottom of it. You can do a search and replace of your input indexes (or write a script to do it for you) and then you can import that using the UI for each space you want to using the UI.

For imports you can also flip the enable flag for the rules you want to auto enable as well so it's designed to be flexible enough for some of these use cases.

You can also use CURL, POSTMAN, REST based tooling with the imports too, depending on how much manual labor you want to remove vs. manual UI based uploading and verification since imports and exports also have API's:
https://www.elastic.co/guide/en/siem/guide/current/rules-api-import.html

[admlko]

Yup, that was also my first thought, write a script which retrieves all rules, loop over customer id's and insert it as prefix or modify query and write it back to a correct space via API.

So, the original question was if Elastic SIEM detection rules support multi-tenancy out of the box. The answer is no, they don't. Thank you @Frank_Hassanabad for your insights!