End-of-Life (EoL)

Multi-Tenant Overview

Cortex XSOAR multi-tenant deployments for MSSPs that require strict data segregation between tenant accounts
Cortex XSOAR multi-tenant deployments are designed for MSSPs that require strict data segregation between tenant accounts and the flexibility to easily share critical security data to those tenant accounts, such as known malicious/benign indicators.
Multi-tenancy also enables MSSPs to manage many tenants from a single console and to easily switch between tenant environments and from a tenant environment to the main environment, where the MSSP can get a bird’s-eye, global view status, for example, all open incidents and indicators across all tenants.

Who Should Use Multi-Tenancy?

Large enterprises that have multiple SOCs often also consider using multi-tenancy, however, in most cases we do not recommend it. The main reason is that enterprise customers expect some degree of collaboration between the SOCs, which, in many respects contradicts the product’s architecture. We therefore suggest in most cases not to use XSOAR multi-tenancy for enterprises and instead use XSOAR Enterprise with proper RBAC implementation and where necessary add additional single servers (e.g., one server per SOC). There are exceptions to these recommendations and we encourage you to consult with XSOAR product managers and customer success to discuss your requirements.

Multi-Tenancy Limitations

When using XSOAR multi-tenancy in an enterprise setting there are several limitations that can negatively impact the enterprise productivity.
  • Complete isolation among tenants. This means that data is not easily shared between tenants. For example, collaborating on an incident requires extra steps (such as mirroring between tenants).
  • Tenants cannot change definitions that were set by the main account (e.g., playbooks, etc.).
  • Multi-tenancy architecture is more complex than XSOAR Enterprise server architecture. It requires heavier IT and computing resources. In general, server maintenance is more difficult and requires a strong IT team.
  • For example, re-indexing a single tenant is a complex procedure and troubleshooting is often very complex.
  • Backup and restore, as well as the DR mechanism are more complex than single server deployments.
  • Since MT environments are more complex, some infrastructure features are introduced only after they are introduced in Enterprise environments.

Multi-Tenancy Architecture

Multi-tenancy architecture is based on the platform’s ability to run multiple instances (processes and data) of the XSOAR server on a single server. Each deployment consists of a main server and tenant accounts. All tenant accounts can reside on the same (main) server or an MSSP can choose to run tenants on additional hosts. Tenants are deployed across hosts for several reasons.
  • Scalability
    : full horizontal scalability - when a server or host is maxed out due to an excess of tenants on the same host, MSSPs can add another host on which to run tenants. MSSPs can easily move tenants between hosts.
  • Geography
    : a global MSSP may have customers in multiple countries or even continents. To increase responsiveness the MSSP may choose to locate a host or multiple hosts in each location.
  • Compliance
    : in some cases MSSPs are asked to run the tenant within the country where the customers’ offices are located or even within the customer’s internal network. For the latter XSOAR supports installing a single host running a single tenant that can be installed on the customer’s premises.

Engines

Direct access to remote networks might be blocked by network devices, such as proxies or firewalls. Cortex XSOAR Engines are installed in a remote network and act as proxies, which enable you to access those remote networks. You can install a single engine, or multiple engines, as a load-balancing group.In MSSP networks, engines are often used to enable the network connectivity between the MSSP’s network and the customer’s local network. Therefore, the engines are installed within the customer’s networks (normally on a local VM situated either in the customer’s DMZ or the security management network) and are programmed to communicate directly to the MSSP’s main server. Once the communication starts a bi-directional tunnel is created between the MSSP and the customer’s network allowing the MSSP to connect to the customer’s relevant resources (e.g. AD, mail server, firewall management server, etc.).

Recommended For You