Step 6. Set up users and roles - Administrator Guide - 8 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Cloud Documentation

Product
Cortex XSOAR
Version
8
Creation date
2024-03-07
Last date published
2024-12-05
Category
Administrator Guide
Solution
Cloud
Abstract

Create user groups and roles, manage users in the Main Tenant, and Authenticate users using SAML 2.0 or the Cortex Gateway in a multi-tenant deployment

Cortex uses role-based access control (RBAC) to manage roles with specific permissions for controlling user access. RBAC helps manage access to components, so that users, based on their roles, are granted the minimal access required to accomplish their tasks.

You can create or configure roles, users, and user groups in Cortex Gateway, the Cortex XSOAR Tenant, or both. For example, create a Manager role in Cortex Gateway, which enables you to maintain the Manager role in a central place with the same level of access for all tenants. If you are using SSO, you create a user group in the Cortex XSOAR tenant that includes the Manager role, assign tenant users to this group and map the user group to your SAML group.

Cortex Gateway and the Cortex tenant have different options and requirements.

Location

Details

Cortex Gateway

A centralized portal for managing roles, user groups, and users for all tenants. Any roles and user groups created in Cortex Gateway are available for all tenants.

Only users with the Account Admin role can manage roles, tenants, and user groups in Cortex Gateway.

If the roles and user groups are created in the Cortex Gateway, roles, permissions, and user groups are propagated to child tenants, not if they are created in the Main Tenant.

Cortex XSOAR Tenant

All permissions and roles are specific to the tenant and exist only at the tenant level. Advanced settings such as default dashboards, queries, and shift management can only be defined per role at the tenant level. Only user groups created on the tenant can be mapped to SAML groups when using SAML SSO.

You need the Account Admin or Instance Administrator role to manage roles, users, and user groups.

You can't create roles and user groups in child tenants when accessing the child tenant from the Main Tenant. Any role or user group created on the Main Tenant does not propagate to the child tenant.

Roles enable you to define permissions for specific components, such as incident data, playbooks, scripts, and jobs. For example, you can create a role that allows users to edit the properties of incidents, but not delete incidents. You can create new roles or customize out-of-the-box roles.

If you assign one or more roles to an incident, only users with those roles can view and interact with the incident. For example, you might have an incident with sensitive data that should only be accessible to Tier-1 analysts and managers.

Roles can also be used to define permissions for integration commands. On the Integration Permissions page, you can assign roles to specific integration instances (all commands for that instance) or specific integration instance commands. For example, you could assign the Generic Export Indicators Service integration instance the Account Admin role, or you could restrict certain commands in the Core Rest API to a specific role. For more information, see Integration Permissions.

  1. Review out-of-the-box roles and role-based permissions.

  2. Create roles in Cortex Gateway.

  3. Create roles in Cortex XSOAR

For more information about out-of-the-box roles, permissions, and how to create roles, see Roles management.

While roles can be assigned directly to users, we recommend instead creating user groups. Each user group has a single role associated with it, but each user group can contain multiple users and user groups can be nested within each other, enabling you to further refine your RBAC requirements. Users can belong to multiple user groups.

After adding users, assign those users to user groups or assign a direct role.

For more information about user groups and how to create them, see User group management.

You can authenticate users by doing one or both of the following options:

  • User authentication in the Customer Support Portal

    Any user who has a Customer Support Portal (CSP) account can be permitted to access your tenants and log in to them through the Cortex Gateway or to the tenant directly. When users log into the Cortex Gateway or the tenant (provided they are assigned a role) they are prompted to sign into the CSP using their username and password. This is the default method of authentication. As soon as they are added to the CSP, you can manage them in the Cortex Gateway or the Cortex XSOAR tenant. You can also manage roles in the Cortex Gateway and the Cortex XSOAR tenant.

    For more information about authentication in Cortex XSOAR, see Set up authentication.

  • SAML Single Sign-On

    Enables the user to log into Cortex XSOAR via SSO, by configuring SSO using SSO. Authenticate users using SAML 2.0 authentication with your identity provider, such as Okta. You define Cortex XSOAR authentication in your identity provider’s account and configure the SSO settings in Cortex XSOAR. SAML 2.0 authentication must be set up separately for your main tenant and each child tenant. There is no propagation of SSO from the Main Tenant to child tenants. For more information, see Authenticate users using SSO.

    Note

    • You can view SSO users from the Cortex Gateway, but SSO users do not have access to the Cortex Gateway.

    • You can have multiple IdP providers with separate SSO configurations on a tenant. For example, for a co-managed tenant, an MSSP and an end customer would use different providers for the same tenant.

If you do not want a user to have access to all tenants, the user should be added using SSO in each tenant. For example, for an MSSP with co-managed tenants (a tenant where management is shared between the MSSP and the end customer), the MSSP’s analysts and the end customer’s analysts need access to the child tenant. If the MSSP’s analysts need access to every child tenant (for multiple end customers), you can either add them in the CSP or through SSO, by configuring SSO for the main tenant and each child tenant. To restrict their access to only one tenant, the end customer’s analysts must have SSO access configured directly on the child tenant. End customer users should not be created as users in the CSP.

If you require users to be automatically propagated to all tenants, you must use the Cortex Gateway. SSO does not propagate from the main tenant to the child tenants.