Shared Tenancy Support

FortiSOAR supports a shared tenancy model for multi-tenancy and MSSP support. A managed security service provider (MSSP) is an IT service provider that provides organizations with some amount of cybersecurity monitoring and management, which may include virus and spam blocking, intrusion detection, and firewalls and virtual private network (VPN) management.

In case of shared tenancy, tenants share the same system as that of the master, i.e., tenants are local, but with restricted access on the system. The master (teams like the SOC team) provides cybersecurity monitoring and management to various tenants (customers/teams) in a single FortiSOAR instance.

You can choose between the Distributed and Shared tenancy models depending on your requirements based on the following points:

• In case of distributed tenancy support, tenants have greater control over the data that they share with the master.
• In case of distributed tenancy, you can avoid additional infrastructure overheads such as, directly connecting the tenant's SIEM to the MSSPs SOAR platform etc.
• Scaling considerations: If you have a large number of tenants then it is easier to scale in case of the distributed tenancy support model, as data primarily resides at the tenant nodes, and the computations also happen at the tenant, a single console at the master node can easily handle multiple customers.

The shared tenancy model ensures that data of different tenants are segregated, and data access is controlled using RBAC (role-based access control). Therefore, a tenant can view only their own data or record and not the data for other tenants.

Each tenant can be given their own login, using which they can view their dashboards, report, check the actions taken on their records, check their SLA management, etc.

The master can extend the Tenants module to include fields that they require for various tenant, such as address of the tenant, tenant SLA, etc. For more information, see the Extending the Tenants module section in the Distributed Tenancy Support chapter.

Steps required for deploying and configuring shared tenancy support

1. Licensing FortiSOAR
   For shared tenancy support, you require a FortiSOAR license that has been enabled for multi-tenancy. Therefore, when you are generating a license in FortiCare, ensure that you generate a license for multi-tenancy support, i.e., a license with edition set to "MT". For more information, see Licensing for Multi-Tenancy section in the Overview chapter.
2. Deploying FortiSOAR
   See the Deploying FortiSOAR chapter in the "Deployment Guide" for detailed information on how to deploy the FortiSOAR Virtual Appliance. For more information, see the Deploying the Master Node section in the Distributed Tenancy Support chapter.
3. Configuring Shared Tenancy
   See the Configuring Shared Tenancy section for configuring and onboarding local tenants.

Configuring Shared Tenancy

Only if your FortiSOAR license has been enabled for multi-tenancy you will see a Multi Tenancy section on your System page.

To see whether your system has been enabled for shared tenancy, you can do the following:

1. Log on to FortiSOAR as an administrator.
2. Click the Settings () icon to open the System page.
3. On the System page, you will see the Multi Tenancy section. Click the Tenants item in the left menu, to view details of the master.
   On the top of the Tenants page, you will see the tenant ID of the master node, and also see Licensed as Master node text.
   

Onboarding tenants

Adding tenants

1. Log on to FortiSOAR as an administrator and click the Settings icon to open the System page.
2. To add tenants, click Tenants in the left menu and on the Tenants page, click Add.
   To edit the configuration of an existing tenant, click the tenant whose configuration you want to update, which opens the agent record in the detail view. Update the configuration parameters as required, and click Save.
   If you no longer require an existing tenant you can deboard that tenant. Deboarding a tenant is an irreversible operation which also deletes all data related to that tenant from the master node. For more information see Deboarding Tenants.
   If you want to deactivate a shared tenant, then you can deactivate the user login for that shared tenant.
3. In the Add Tenant dialog, configure the following parameters:
   1. From the Choose Tenant Type field choose the type of tenant you want to add.
      In this case, select Shared to add this tenant as a local tenant of the master, i.e., in the same FortiSOAR instance for shared tenancy. Local or Shared tenants, based on their permissions, share the current FortiSOAR instance with the Master.
   2. In the Name field, enter the name of the tenant.
   3. (Optional) In the Description field, enter the description of the tenant.
   4. From the Owners drop-down list, select the teams that you want to add as an owner to the records coming from this tenant and click Link Team.
      The teams that you have selected and the SOC Admin team (considering that the tenant has been created using the SOC Admin team) will be associated as owners of any record created for that tenant. If no team is selected, then the teams that the user who adds the tenant belongs to will be associated as owners of any record created for that tenant.
   5. To complete adding a new tenant associated with the master node, click Save.
      As tenants are wrappers, no configuration state is associated with a tenant and you also do not need to create an agent, since everything in case of a shared tenant runs only on the master instance using the master agent. However, if you require to run some actions on a separate network, then you can add and configure another agent, and then associate that with the shared tenant.
   6. To link an agent with a shared tenant, open the record of the shared tenant and in the Owners section, click the Agents tab, and click Link to open the Link Agents dialog that contains a list of configured agents. Select the agent that you want to associate with the shared tenant and click Save Relationship:
      
      Once you have linked an agent you can expand the row of the shared tenant and check the connection between the agent and the master node using secure message exchange. Once the connection is established from the master node to the agent, the Status field displays "Remote Node Connected".
      

List of Statuses

Following is the list of statuses that can be displayed:

• Configuration In Progress: Process of configuring the agent has begun.
• Awaiting Remote Node Connection: Connection between the FortiSOAR node and secure message exchange is established and awaiting the connection to the agent.
• Remote Note Connected: Agent has been connected to the FortiSOAR node using secure message exchange.
• Configuration Failed: Agent failed to be added on the secure message exchange.
• Message Exchange Unreachable: Secure message exchange is unreachable.
• Remote Node Unreachable: Agent is unreachable from the FortiSOAR node.

Associating the tenant with teams and users

If you have not associated the tenant with teams at the time of adding tenants (step 3e of the previous procedure), then once you have created a tenant, you must associate the tenant to team(s). Tenants must be associated with teams so that all records created for a given tenant are automatically owned by the same teams who are associated with the tenant. For example, if alerts are created whose tenant is set as T01, then only the teams associated with team T01 and their ancestors in the team hierarchy will be able to view the alert record.

Steps mentioned in the following sections describe how to add a team and then associate the tenant with that team.

Once you associate the tenant with teams you must also assign users to those teams, as mentioned in the following Adding a user to a team section.

Adding a Team

To add a team, click the Settings icon and in the Security Management section click Teams. Click Add Team to display the Add Team dialog and enter the name of the team that you want to create, for example, Tenant-L01 and optionally add a description for the team and click Create to add the new team.

Associating the tenant with the teams

You should now associate the tenant with this newly created team, so that records created in this tenant will be owned by the team. You must also link a management or master team, such as the SOC Team with the tenant, or ensure that the master team is at the top of the team hierarchy, so that record will be visible to the master.

To assign the tenant to a team, click the Settings icon and in the Multi Tenancy section click Tenants. Click the tenant that you want to assign to the team, for example, Tenant-L01, which opens the tenant record. In the tenant record, click Link, and in the Link Teams dialog, select the team that you want to associate with the tenant. In our example, select the Tenant-L01 and SOC Team team and click Save Relationship:

Adding a user to a team

The users in the team that you have created should be assigned to a role with a minimum of Read permission on the Application, Tenants, and People modules, apart from required permissions on the case management modules, like Alerts, Incidents, Tasks, etc. You must not assign these users any Security permissions. It is also recommended that you should not assign any Playbook or Connector permissions to these users, if you do not want them to run any playbooks.

You can create a new role (for example Tenant Role) with the recommended permissions and assign them to the users that you want to assign to the Tenant team.

For example, a user named Tenant User, who you want to create as a tenant user, should be added or linked to the team selected as Tenant-L01 and role assigned as Tenant Role:

Deboarding tenants

You might want to deboard existing tenants due to the following reasons:

• Tenant has not been configured correctly and you are required to remove the tenant and then add the tenant back.
• You (service provider) no longer manages the tenant.

To deboard existing tenants, you require to have Read and Delete permissions on the Tenants module. Deboarding tenants not only deletes the tenant from the master node, but also removes all information and data associated with that tenant from the master node. Once you delete a tenant, you cannot retrieve any information related to that tenant, therefore you must be careful while performing this operation.

To deboard a tenant, log on to FortiSOAR as an administrator and click the Settings icon to open the System page. Click Tenants in the left menu and on the Tenants page, click Delete. FortiSOAR will display the following warning dialog:

To deboard the tenant, click Confirm on the warning dialog.

Once you deboard a dedicated tenant, the associated dedicated agent is also removed and other agents unlink themselves from the tenant.

Example of editing the templates to add the Tenant field

In the ingestion playbooks, you must ensure that the tenant field is correctly set on the created records. While creating records manually, you must take care that the tenant field is defined. If no tenant is defined, the 'self' tenant gets associated with the record.

You (administrators of the master team) should edit the templates (SVT), for the modules in which tenants will create records, for example, Alerts, to include the Tenant field when a user is creating a record.

To edit the SVT, navigate to the module for which you want to update the SVT, for example, Alerts, open a record and click Edit Template. On the Template Editing Mode Enabled page, in the appropriate widget, such as Form Group Details click Edit, add the Tenant field, and then click Add. Click Save to save your changes to the SVT.

When an alert from a tenant is added, for example Repeated Login Failures, then the Tenant field the name of tenant associated with this record gets populated, thereby enabling the master to easily identify which records belong to which tenant. If no tenant is assigned while adding the alert, i.e., if the alert is created on the master, then that record is created as a Self record, i.e., Self will appear in the Tenant column.

Once a record is created, from version 7.0.2 onwards, if the value of the tenant associated with a record is set to "Self", then you are allowed a one-time edit of the tenant field. This is because at the time of record (alert) creation, the tenant to be mapped to the alert is not uniquely identifiable. Only after extraction and enrichment of the alert can the tenant be correctly determined.

The following image displays a view on the master with alert records from different tenants:

Now the master can perform all required actions such as running investigative playbooks, on this alert record and provide cybersecurity management to the tenant.