Multitenancy

Kaspersky Next XDR Expert supports a multitenancy mode. This mode enables the main administrator to provide the Kaspersky Next XDR Expert functionality to multiple clients independently, or to separate assets, application settings, and objects for different offices. Each client or office is isolated from others and is called a tenant.

Typically, the multitenancy mode is used in the following cases:

• A service provider has a number of client organizations and wants to provide the Kaspersky Next XDR Expert functionality to each client organization independently. To do this, the service provider administrator can create a tenant for each client organization.
• An administrator of a large enterprise might want to isolate assets, application settings, and objects for the offices or organization units and manage the offices or organization units independently. To do this, the administrator can create a tenant for each office or organization unit.

The multitenancy mode has the following features:

• Tenant isolation
• Cross-tenant scenarios

Tenant isolation

A tenant is isolated and managed independently from other tenants. Only users who have assigned access rights to the tenant can work within this tenant and manage it. The tenant's data, resources, and assets cannot be accessed by an administrator of another tenant unless the main administrator grants the corresponding access rights to the administrator explicitly.

For each tenant, you define a number of objects, including the following ones:

• Assets

  The asset list is unique for each tenant. Each asset can belong to one tenant only.

• Users and their access rights
• Events, alerts, and incidents
• Playbooks
• Integration with other Kaspersky applications, services, and third-party solutions

Cross-tenant scenarios

All tenants are arranged into a tenant hierarchy. By default, the tenant hierarchy contains a pre-created Root tenant at the top of the hierarchy. No other tenants can be created at the same level as the Root tenant. You create a new tenant as a child to any existing tenant, including the Root tenant. The tenant hierarchy can have any number of nesting levels.

The tenant hierarchy is used to provide cross-tenant scenarios, including the following ones:

• Inheritance and copying

  A child tenant receives the following objects from the parent tenant:

  • Users and their access rights

    Access rights are inherited down by the hierarchy and cannot be revoked on a lower level of the hierarchy.

  • Tenant settings, including integration settings, and playbooks

    Tenant settings and playbooks are copied from a parent tenant to its child tenant. After the child tenant is created, you can reconfigure the copied settings to meet the requirements of the new tenant.

• Licensing

  A license key for Kaspersky Next XDR Expert is applied at the level of the primary Administration Server that is bound to the Root tenant. Then, the license key is automatically applied to all of the tenants in the hierarchy.

User roles

Kaspersky Next XDR Expert provides you a predefined set of user roles. You grant user rights to manage tenants by assigning user roles to the users.

Tenants and Kaspersky Security Center Administration Servers

You can bind tenants to Kaspersky Security Center Administration Servers, physical or virtual. A link between a tenant and an Administration Server allows you to combine features of both solutions—Kaspersky Next XDR Expert and Open Single Management Platform.

Tenant filter in the application interface

In the Kaspersky Next XDR Expert interface, you can configure object lists to display only those objects that relate to the tenants that you select. The tenant filter applies to the following objects:

• Alerts in the Alerts section
• Incidents in the Incidents section
• Events in the Threat hunting section
• Playbooks in the Playbooks section

When you apply the tenant filter, the new settings are applied to all of the object types across the interface and in both consoles—OSMP Console and KUMA Console.

About binding tenants to Administration Servers

You can bind tenants to Kaspersky Security Center Administration Servers. A link between a tenant and an Administration Server allows you to relate the assets managed by the Administration Server to the tenant.

You cannot bind tenants to virtual Administration Servers, only to physical ones.

Tenants can have subtenants; therefore they are arranged into a tenant hierarchy. Administration Servers can have secondary Administration Servers; therefore they are arranged into a Server hierarchy. You cannot bind an arbitrary tenant to an arbitrary Server because this may lead to an illegal binding. For example, a user may not have access rights to a tenant in the tenant hierarchy, but the same user may have access rights to the devices of this tenant. This might happen if this user has access rights to the Administration Server 2 which is primary to the Administration Server 1 bound to the tenant. Therefore, by default, this user has inherited access rights to the Administration Server 1 and its managed devices. To eliminate such a situation, tenants and Administration Servers can only be bound to each other according to the binding rules.

There are two types of bindings:

• Explicit binding

  This binding type is established when you select an Administration Server to which you want to bind a tenant.

• Inherited binding

  When you establish explicit binding to an Administration Server that has secondary Administration Servers, the secondary Administration Servers are bound to the tenant through the inherited binding type. Therefore a tenant may be bound to several Administration Servers.

Binding rules:

• The Root tenant is always bound to the root Administration Server, you cannot remove this binding.
• A tenant may be not bound to an Administration Server. Such a tenant can have subtenants, and these subtenants can be bound to Administration Servers.
• You can bind two Administration Servers which are arranged into a hierarchy only to two tenants which are arranged into a hierarchy too, and only if the hierarchy of Administration Servers matches the hierarchy of tenants.
• An Administration Server may be bound only to one tenant, explicitly or through the inherited binding type.
• When you bind a tenant to an Administration Server explicitly:
  • If the Administration Server was bound to another tenant explicitly, this binding is automatically removed.
  • If the Administration Server has secondary Administration Servers, the secondary Administration Servers are bound to the new tenant through the inherited binding type excluding those Administration Servers that were bound to their tenants explicitly. Before this operation, Kaspersky Next XDR Expert checks whether or not all of the new bindings are legal. If they are not, the binding cannot be established.
• When you remove an explicit binding between a tenant and an Administration Server (unbind Administration Server), the Administration Server and all of its secondary Administration Servers (if any) are automatically bound through the inherited binding type to the tenant to which the primary Administration Server of the selected Administration Server is bound. If some of the secondary Administration Servers are bound to their tenants explicitly, those Administration Servers keep their bindings.
• When you add a new Administration Server to the hierarchy, the Administration Server is automatically bound through the inherited binding type to the tenant to which the Server's primary Administration Server is bound.
• When you remove an Administration Server from the hierarchy and the Administration Server has an explicit binding to a tenant, this binding is removed.

Configuring integration with Open Single Management Platform

You can bind tenants to Kaspersky Security Center Administration Servers. A link between a tenant and an Administration Server allows you to relate the assets managed by the Administration Server to the tenant.

You cannot bind tenants to virtual Administration Servers, only to physical ones.

Before you begin:

• Make sure that you are familiar with the binding rules.
• You have created the tenant that you want to bind to an Administration Server.
• If required, you have added the secondary Administration Server that you want to bind to the tenant.

To bind a tenant to an Administration Server or unbind it from the Server, you must have a role that grants the Write access right to the Tenants and Integrations functional areas.

Binding a tenant to an Administration Server

To bind a tenant to an Administration Server:

1. In the main menu, go to Settings → Tenants.

   The tenant list opens. The list contains only the tenants to which you have at least the Read access right.

2. Click the name of the required tenant.

   The tenant properties window opens.

3. On the Settings tab, select the check box next to the tenant that you want to bind to an Administration Server, and then click the Bind Administration Server button.
4. In the window that opens, select the Administration Server that you want to bind to the tenant.

   If you want to add a new Server to the hierarchy or delete an existing one, you can do it in the Administration Server properties.

5. Click the Bind button.

The binding process may take a while. You can track this process in the Binding status column of the Administration Server list in the tenant properties window.

Unbinding a tenant from an Administration Server

To unbind a tenant from an Administration Server:

1. In the main menu, go to Settings → Tenants.

   The tenant list opens. The list contains only the tenants to which you have at least the Read access right.

2. Click the name of the required tenant.

   The tenant properties window opens.

3. On the Settings tab, select the check box next to the tenant that you want to unbind from an Administration Server, and then click the Unbind button.

Viewing and editing tenants

You can use tenants to provide the Kaspersky Next XDR Expert functionality to a client organization independently, or to separate assets, application settings, and objects for different offices.

To view or edit a tenant's properties:

1. In the main menu, go to Settings → Tenants.

   The tenant list opens. The list contains only the tenants to which you have at least the Read access right.

2. Click the name of the required tenant.

   The tenant's properties window opens. If you have only Read access right to this tenant, the properties will be opened in read-only mode. If you have the Write access right, you will be able to modify the tenant's properties.

3. Modify the tenant's properties, and then click the Save button.

The tenant's properties are modified and saved.

General

The General tab contains general information about the tenant. You can modify the tenant's name and description.

Settings

The Settings tab contains the following sections:

• Kaspersky integrations

  This section allows you to configure integration settings for the Kaspersky applications that you want to integrate into Kaspersky Next XDR Expert for the current tenant.

• Third-party integrations

  This section allows you to configure integration settings for third-party applications that you want to integrate into Kaspersky Next XDR Expert for the current tenant.

• Detection and response

  This section allows you to configure settings and objects related to threat detection and response:

  • Retention period

    Retention periods for alerts and incidents depend on the Kaspersky Next XDR Expert license that you use.

  • Email templates
  • Segmentation rules
  • Aggregation rules
  • Incident management
  • Mail server connection

You do not need to configure the settings of the shared tenant.

Roles

The Roles tab lists the users who have access rights to the tenant. You can change this list and assign user roles to the users.

Adding new tenants

Before you begin, read general information about tenants.

To add child tenants, you must have the Read and Write rights in the Tenants functional area on the parent tenant or on a tenant of a higher level in the tenant hierarchy.

To add a new tenant:

1. In the main menu, go to Settings → Tenants.
2. Select the check box next to the parent tenant. The new tenant will be created as a child to the selected tenant.
3. Click the Add button.
4. In the Add tenant window that opens, enter the name of the new tenant.
5. If necessary, add a description for the new tenant.
6. Click the Add button.

The new tenant appears in the tenant list.

A child tenant inherits the following objects from the parent tenant:

• Users and their access rights
• Integration settings

After a tenant is created, you can reconfigure the inherited objects to meet the requirements of the new tenant.

Assigning roles to users in a tenant

You can assign XDR roles to the Kaspersky Next XDR Expert users to provide them with sets of access rights in a tenant.

To do this, you must have one of the following XDR roles in the tenant in which you want to assign roles to users: Main administrator, SOC Administrator, or Tenant Administrator.

Since tenants are isolated and managed independently from other tenants, only users who have assigned access rights to the tenant can work within this tenant and manage it.

Access rights are inherited down in the hierarchy and cannot be revoked on a lower level of the hierarchy.

To assign roles to а user in a tenant:

1. In the main menu, go to Settings → Tenants.

   The list of tenants is displayed on the screen.

2. Click the name of the required tenant.

   The tenant's properties window opens.

3. Go to the User roles tab, and then click Add user.
4. In the window that opens, do the following:
   1. In the User field, enter the user name or email address.
   2. Select the check boxes next to the roles that you want to assign to the user.

      You can select several roles, if necessary.

   3. Click the Add button.

   The window is closed, and the user is displayed in the list of the users.

5. Click the Save button.

The user is added to the tenant and assigned roles. If necessary, you can edit the user roles by clicking the user name, and then performing the actions described at steps 4–5.

Deleting tenants

You can delete only one tenant at a time. However, if the selected tenant has child tenants, they will be deleted as well. The playbooks related to the tenant will be deleted, and information about alerts and incidents related to the tenant will become unavailable.

When you delete a tenant in OSMP Console, the following changes occur in KUMA Console:

• Tenant, its resources and assets are deleted.
• Sorage partitions related to the tenant are deleted.
• Raw events become unavailable.
• Services status of the deleted tenants change to Gray.

To delete a tenant, you must have the Read and Write rights in the Tenants functional area on the selected tenant.

You cannot delete the Root tenant and the tenants that were migrated from the integrated applications (for example, Kaspersky Unified Monitoring and Analysis Platform) and marked as non-deletable in those applications.

To delete a tenant:

1. In the main menu, go to Settings → Tenants.

   The tenant list opens. The list contains only the tenants to which you have at least the Read access right.

2. Select the check box next to the tenant that you want to delete. If the selected tenant has child tenants, they will be selected automatically and you cannot unselect them.
3. Click the Delete button.
4. Confirm the operation by typing the name of the tenant that you want to delete. If the tenant has child tenants, they are listed as tenants to be deleted as well.

The selected tenant, its child tenants (if any), and related objects are deleted.

Configuring a connection to SMTP

You can configure email notifications about events occurring in Kaspersky Next XDR Expert via Kaspersky Security Center Administration Server and an external SMTP server. To do this, you must configure connection settings to an SMTP server.

To configure connection to an SMTP server:

1. In the main menu, go to Settings → Tenants.

   The list of tenants is displayed on the screen.

2. Click the name of the required tenant.

   The tenant's properties window opens.

3. Go to the Settings tab, and then in the Detection and response section, click Mail server connection.
4. In the right pane, click the View properties button.

   The Administration Server properties window opens with the General tab selected.

   The window displays properties of the primary Administration Server and SMTP settings for the primary Administration Server, no matter to which Administration Server the tenant is bound.

5. Configure the parameters, as described at step 2 in Configuring notifications delivery.

After you configure connection to an SMTP server, the users will start receiving email messages from Kaspersky Next XDR Expert.

Configuring notifications templates

After you configure the connection to an SMTP server, you can configure templates for email notifications about events occurring in Kaspersky Next XDR Expert.

To edit notifications templates, you must have one of the following XDR roles: Main administrator, Tenant administrator, or SOC administrator.

When you deploy Kaspersky Next XDR Expert, you have the templates for email notifications in the Root tenant. If you create a child tenant, it automatically copies the settings from the parent tenant. Since child and parent settings are not related, the changes you make in a child tenant settings do not affect the settings in the parent tenant, and vice versa.

To configure email notifications templates:

1. In the main menu, go to Settings → Tenants.

   The list of tenants is displayed.

2. Click the name of the required tenant.

   The tenant's properties window opens.

3. Go to the Settings tab, and then in the Detection and response section, click Email templates.

   The table of the event types for which you can configure notifications templates is displayed.

4. If at step 2 you selected the Root tenant, in the Enter server name field, enter the address to be used in links to alerts and incidents in the email messages.
5. In the Event type column of the table, click the name of the notification template that you want to edit: Creating a new alert, Assigning an alert to an operator, Automatic creation of a new incident, Assigning an incident to an operator.
6. In the Edit email template window that opens, do the following:
   • If you want to enable email notifications for the selected event type, move the toggle button to the Enabled position in the Status field.

     By default, email notifications are disabled. You can enable email notifications from the table of the event types by moving the toggle button to the Enabled position.

   • In the Subject field, specify the subject of the email notification.

     You can access the alert fields, incident fields, and KUMA normalized event fields, for example, New incident in OSMP: {{ .InternalID }}, {{ .Name }}.

   • In the Template field, write the email notification message.

     Example of the email notification message.

     Hello,<br> <br> Alert {{ .InternalID }}{{ with escapeHTML .Rules.Names }} "{{ . }}"{{ else }}{{ end }} was registered at {{ .CreatedAt }}.<br> <br> Details on alert:<br> <br> Tenant: {{ .TenantID }}<br> Alert severity: {{ .Severity }}<br> Alert first seen: {{ .FirstEventTime }}<br> Alert last seen: {{ .LastEventTime }}<br> Full information about the alert is available in OSMP web-interface: {{ link_alert . }}<br> <br> Open Single Management Platform

     You can access the alert fields, incident fields, and KUMA normalized event fields, and use HTML tags.

     When writing a template, you can use the following functions:

     • date—Defines date and time format. The function takes the time in milliseconds (UNIX time) as the first parameter. The second parameter can be used to pass the time in the RFC standard format. The time zone cannot be changed.
       {{range .Events }} Service name: {{.Event.ServiceName}} Device host name: {{.Event.DeviceHostName}} Message: {{.Event.Message}} {{end}}

       Nested objects can have their own nested objects. You can access them using nested range functions.

     • limit—Limits the number of objects returned by the range function.
     • link_alert—Generates a link to the alert, with the URL specified in the Enter server name field.
     • link_incident—Generates a link to the incident, with the URL specified in the Enter server name field.
     • link—Takes the form of a link that the user can open when he/she receives the notification email.
   • In the Recipients field, specify one or several email address for sending notifications.
   • If necessary, in the Description field, write a description of notification template.
7. Click the Confirm button.

   The Edit email template window is closed.

8. Click the Save button to save the changes.

The template for email notifications is edited and configured. When the selected types of events occur in Kaspersky Next XDR Expert, the template notifications are sent to the email addresses that you specified.