This section provides information about configuring multitenancy in Sentinel.
You can create tenants in the Tenants interface and then associate the tenant name to events when configuring Sentinel for data collection.
To create tenants:
From Sentinel Main, click Users > Tenants.
In the Create New Tenant field, specify the tenant name and click Create Tenant.
By default, tenants are enabled and you can associate tenants to events when collecting data.
You can also create tenants when configuring the Collector for data collection. For more information, see Associating Incoming Events with a Tenant.
Multitenancy starts with properly identifying the data coming from each tenant. If each tenant hosts their own Sentinel infrastructure (outsourced SOC model), no action is required.
For all other MSSP models, every incoming event should include the tenant name in the TenantName (rv39) field. This is handled at the Collector level as a Collector property. The implication is that all the data that passes through a single Collector must belong to a single tenant. If there are multiple tenants sending data from the same type of event source, you should deploy individual instances of the appropriate Collector for each tenant to split the data and specify the TenantName in the Collector parameter. The Collector then adds the TenantName to the event field as specified by the parameter. The Collector also generates a unique ID for each tenant in the tid (TenantID) field.
You can assign a tenant name to events when configuring the Collector for data collection. Each tenant must have a dedicated Collector so that their data can be identified with their tenant name. You can have multiple event sources forward data to one Collector, however, all event sources for the Collector must be from one tenant.
To assign a tenant name:
Access Event Source Management.
For more information, see Accessing Event Source Management.
Locate the Collector Manager that is associated with the Collector.
Right-click the Collector Manager, then select Add Collector.
In the Configure Collector Property tab, specify the tenant name in the Tenant Name field.
For more information about data collection, see Section 6.0, Configuring Agentless Data Collection.
The tenant information that you add in the Collector sets up a namespace, which you can use to configure other functions of Sentinel. For example, the identity and host (asset) information that Sentinel receives is transferred to maps for the mapping Service. In the case of the Identity Manager Sentinel Driver, you can set the tenant name in the driver parameter. This means that the mapping service and identity services can function properly even if the same IP addresses or user account names are present in more than one tenant environment.
For information about mapping, see Section 11.0, Mapping Events. For information about Identity Manager Sentinel Driver, see the Driver for Sentinel Implementation guide.
If tenants host their own Sentinel server or if you host separate Sentinel server instances for each tenant, data segregation is straightforward. If you have a centralized Sentinel server for multiple tenants, you can design data retention policies to split each tenant data into separate partitions.
You should define at least one retention policy to segregate event data from different tenants into different folders for each tenant. When creating retention policies for each tenant, specify the Criteria as tid:"tenant_ID" where tenant_ID is the ID of the tenant.
Each retention policy creates a separate partition so that you can manage it separately. Sentinel saves the event file in a folder in the format YYYYMMDD_<Data Retention Policy ID>. Therefore, with an unique retention policy for each tenant, you can achieve event data segregation on the folder level.
Setting up a data retention policy helps you in the following ways:
Flexibility to define data retention parameters for each tenant according to their requirements.
Ensures that each tenant data is physically separated in different folders.
NOTE:The recommendations above apply to parsed event data. Sentinel automatically segregates raw data if you configured individual Collector instances for each tenant.
For more information about data retention policies, see Section 14.0, Configuring Data Retention Policies.
Tenants who host their own Sentinel server (SOC outsourcing model), will probably create their own users and roles to provide or limit data access. For all other MSSP models, the MSSP decides whether tenants should have access to the Sentinel system and if so, to what data.
If each tenant has a unique Sentinel instance, you can use standard role definitions and users for the tenant. For more information, see Section 4.0, Configuring Roles and Users.
If multiple tenants have access to the same Sentinel instance, it is important to configure the system to restrict access appropriately. Sentinel provides the ability to define tenants, tenant-specific roles, and tenant-specific users. When creating roles, you can select the relevant tenant name for the role. Users in that role can see data and real-time views specific to only the tenant they belong to. You can assign the default tenant for MSSP employees who need to view multiple tenants' data, which gives them access to data and real-time views of all the tenants.
Tenant roles, and the users assigned to them, have a tenant-specific filter built in by default. You can add additional security filters (for example, a filter for operating system events only) as needed. The intersection of the tenant and security filters applies to searches, reports, real-time views, and dashboards.
You can also delegate the responsibility of administering a tenant's roles and users to the tenant by assigning the Manage roles and users permission to the tenant. For more information, see Section 4.0, Configuring Roles and Users.
You can now restrict the access of the visual analytics features like Discover, Dashboard, DevTools, and Management by giving the appropriate visualization permissions. For more information about the visualization permissions, see Creating a Role.
This section provides information about configuring various Sentinel functions for multi-tenancy.
You can create a filter for each tenant to use in constructing more complex criteria, which you can use in searches and other places the criteria is called for. When you create a filter, specify the Criteria as tid:"tenant_ID" (where tenant_ID is the ID of the tenant). For more information about creating filters, see Configuring Filters
in the Sentinel User Guide.
You can set up the following types of dynamic lists:
Dynamic lists that are global to all tenants. For example, you might want to create a black list of well-known bad IP address ranges.
Dynamic lists that are specific to particular tenants. For example, a list of important assets or privileged accounts. In this case, you should create the following:
A separate dynamic list for each tenant
A separate correlation rule for each tenant to refer to the specific dynamic list
A separate action to write to a specific dynamic list
For information about creating dynamic lists, see Configuring Dynamic Lists
in the Sentinel User Guide.
WARNING:In any MSSP model where multiple tenants send data to the same Sentinel instance, you must configure correlation rules correctly to ensure that the TenantID field is populated. This ensures that automatic tenant filtering applies to keep correlated events and alerts private. If TenantID is not populated, there is a risk of one tenant seeing another tenant’s data.
The following guidelines apply if you want to create a correlation rule that should run only for a single tenant:
For correlation rules that fire based on a single event, append AND tid="Tenant_ID" to the correlation rule criteria. The correlated event automatically populates the TenantID field in the correlated event output.
For correlation rules that fire based on multiple events, gate rules, and sequence rules, append AND tid="Tenant_ID" to the rule criteria. Set the TenantID field to the ID of the tenant in the correlated event output.
You can use tenant-specific (for example, “Tenant A Critical Servers”) or cross-tenant (MSSP) dynamic lists.
You can use a tenant-specific action (for example, “Send email to Tenant A”) or an MSSP action (for example, “Send email to MSSP analyst”).
The following guidelines apply if you want to create a correlation rule that runs for all tenants and creates output that is viewable by each individual tenant.
For rules that fire based on a single event, you do not need to filter by tenant. The correlated event automatically populates the TenantID field based on the trigger event.
For rules that fire based on multiple events, gate rules, and sequence rules, you do not need to filter by tenant. You should group by the TenantID field. The correlated event automatically populates the TenantID field.
You can add a filter that includes multiple tenants if the rule should only be run for a subset of tenants.
Use only cross-tenant (MSSP) dynamic lists. For example, Known Bad Source IPs.
Use only cross-tenant (MSSP) actions. For example, Send email to MSSP analyst.
The following guidelines apply if you want to create a correlation rule that runs across all tenants and creates output that is viewable only by the MSSP (Sentinel Administrator).
For rules that fire based on a single or multiple events, gate rules, and sequence rules, you do not need to filter by tenant. You do not need to group by the TenantName field since you want the rule to run across tenants. Set the TenantName field to default in the correlated event output to ensure only the MSSP users will see the events and alerts.
You can add a filter that includes multiple tenants if the rule should be run only across a subset of tenants.
Use only cross-tenant (MSSP) dynamic lists. For example, Known Bad Source IPs.
Use only cross-tenant (MSSP) actions. For example, Send email to MSSP analyst.
For more information about creating correlation rules, see Correlating Event Data
in the Sentinel User Guide.
When creating real-time views such as event views and alert views, you can specify the tenant name for which you want to view data. This is applicable only for MSSP employees assigned to the default tenant since they need to view multiple tenants' data. Roles assigned to specific tenants automatically have the tenant's filter applied and can view only the data specific to their tenant.
For more information, see the specific chapters in the Sentinel User Guide.