Provision, authenticate, and map users in the Google SecOps platform

Supported in:

Google SecOps

This article shows you how to provision, authenticate, and map users with secure identification to the Google Security Operations platform. This page illustrates the configuration process using Google Workspace as the external IdP. The process is similar in other external IdPs.

Set up SAML attributes for provisioning

First, you need to set up the SAML attributes and the SAML groups in the external identity provider (IdP).

1. Navigate to the SAML Attributes mapping section in the Google Workspace.
2. Add the following four mandatory attributes:
   • first_name
   • last_name
   • user_email
   • groups
3. In the Google Groups section, write the names of the IdP groups. For example, Chronicle Admins or Gcp-security-admins. Make a note of these group names; you need them later for mapping in the Google Security Operations platform. (In other external providers, such as Okta, this is referred to as IdP Groups.)

   

Set up IdP provisioning

Follow the instructions under Configure the IdP as well as the instructions under workforce identity federation.

Below is the workforce pool creation command for the app configuration discussed in Step 6 in Configure workforce identity federation:

gcloud iam workforce-pools providers create-saml WORKFORCE_PROVIDER_ID \
  --workforce-pool=WORKFORCE_POOL_ID \
  --location="global" \
  --display-name=WORKFORCE_PROVIDER_DISPLAY_NAME \
  --description=WORKFORCE_PROVIDER_DESCRIPTION \
  --idp-metadata-path=PATH_TO_METADATA_XML \
  --attribute-mapping="google.subject=assertion.subject,attribute.first_name=assertion.attributes.first_name[0],attribute.last_name=assertion.attributes.last_name[0],attribute.user_email=assertion.attributes.user_email[0],google.groups=assertion.attributes.groups"

Control user access

There are several different ways to determine which users have access to which aspects of the platform.

• Permissions groups: set permissions groups for user types. Permission groups determine which modules and submodules are visible or editable for users. For example, you can set permissions such that the user will see the Cases and the Workdesk pages but not have access to the Playbooks and Settings pages. For more information, see Working with Permission Groups.
• SOC roles: Define the role of a group of users. You can assign cases or actions or playbooks to a SOC role instead of to a specific user. Users will see cases that are assigned to them, their role, or to one of the additional roles. For more information, see Working with Roles.
• Environments: Set environments to be used by enterprises to manage different networks or business units within the same organization. Users will only see data for those environments they have access to. For more information, see Adding an environment.

Map and Authenticate Users

The combination of permission groups, SOC roles, and environments determines the Google SecOps user journey for each IdP group in the Google SecOps platform.

You need to map each IdP group that you defined in the SAML settings procedure in the IdP Group Mapping page.

There are various options for mapping. You can choose to map IdP groups with multiple permission groups, SOC roles and environments. This ensures that different users mapped to different IdP groups in the SAML provider inherit all the necessary permission levels. For more information, including how Google Security Operations handles this, see Multiple permissions in IdP group mapping.

You can also choose to map IdP groups to individual control access parameters. This enables a more granular level of mapping and can be helpful for large customers. For more information, see Map IdP groups to access control parameters.

By default, the Google SecOps platform includes an IdP group of default admins.

To map IdP groups,follow these steps:

1. In the Google Security Operations platform, navigate to Settings > SOAR Settings > Advanced > IdP Group Mapping.
2. Make sure you have the names of the IdP groups at hand.
3. Click add and start mapping the parameters for each IdP group.
4. When you have finished, click Save. When each user logs in to the platform, they are automatically added to the User Management page (which is located in Settings > Organization ).

Sometimes users will try to log into the Google SecOps platform but their IdP group has not been mapped in the platform. In order for these users not to be rejected, we recommend enabling and setting the Default Access Settings on this page.

Note: This feature is covered by Pre-GA Offerings Terms of the Google Security Operations Service Specific Terms. Pre-GA features might have limited support, and changes to pre-GA features might not be compatible with other pre-GA versions. For more information, see the Google Security Operations Technical Support Service guidelines and the Google Security Operations Service Specific Terms.

Multiple permissions in IdP group mapping

This section describes the algorithms that the platform uses to apply multiple permissions for user groups.

Permission groups

Each user or user group can be mapped with up to five permission groups. The users get a combination of all the permissions from each of the permission groups.

Landing page on login

Each permission group has an assigned platform page that users of that group land on when they first log in to the platform. When a user or user group is mapped to multiple permission groups, Google SecOps chooses the landing page that is highest according to the following hierarchy:

• Cases > Case Overview
• Homepage (Workdesk) > My Cases
• Cases > Case Wall
• Homepage (Workdesk)> Pending Actions
• Dashboards
• Playbooks
• Reports
• Search
• Homepage (Workdesk) > Requests
• Command Center (Incident Manager)
• Legacy SIEM Search

Restrict actions

Each permission group has a section where the admin can choose actions that are restricted for that specific permission group. The restricted action must be selected in all permission groups that are assigned to the user group. In other words, if the user group is mapped to several permission groups but only assigned a restricted action in one of those permission groups, they will not be restricted.

SOC roles

Each user can be mapped with up to five SOC roles plus additional roles.

Playbook views per SOC roles

Each playbook customized view is assigned to a specific SOC role. If a user is assigned to several SOC roles, then all widgets are displayed. The exception to this is if one SOC role includes another SOC role, then in this scenario, the parent SOC role's playbook view is displayed.

Environments

Each user can be assigned to multiple environments and has access to all the cases and data for each environment.

Map IdP groups to access control parameters

This section describes how to map different IdP groups to one or more access control parameters within the IdP Group Mapping page. This style of mapping is useful for customers who want to onboard and provision their user groups according to specific customizations and not according to the Google Security Operations SOAR platform standardization. Mapping different IdP groups to one or more parameters means that while you will need to create more IdP groups in your SAML provider, once you have everything mapped out, new users can join Google Security Operations without needing to create new IdP groups.

Use Case: Setting different IdP groups to different permission fields

The following example illustrates how to use this feature to help onboard and provision users according to your company's needs.

Your company has three different personas:

• Security Analysts (Includes group members Sasha and Tal)
• SOC Engineers (Includes group members Quinn and Noam)
• NOC Engineers (Includes group members Kim and Kai)

Security Analysts and SOC Engineers have the same Google Security Operations SOAR Permission Group (Admin) and SOC Role (Admin) but the Security Analysts have permissions for the London environment and the SOC Engineers have permissions for the Manchester environment. Meanwhile, NOC Engineers have permissions for the London environment but are assigned the BasicPermission Group and Tier 2 SOC Role. This is depicted in the table below:

Persona	Permission Group	SOC Role	Environment
Security Analysts	Admin	Admin	London
SOC Engineers	Admin	Admin	Manchester
NOC Engineers	Basic	Tier 2	London

For the purposes of this example, we are assuming that all the necessary Permission Groups, SOC Roles and Environments have been set up in the Google Security Operations platform already.

Here is how you would set up the IdP groups in the SAML provider and in the Google Security Operations platform:

1. In your SAML provider, create the following user groups:
   1. Security Analysts (containing Sasha and Tal)
   2. SOC Engineers (containing Quinn and Noam)
   3. NOC Engineers (containing Kim and Kai)
   4. London (containing Sasha, Tal, Kim and Kai)
   5. Manchester (containing Quinn and Noam)
2. In the Google Security Operations platform, go to Settings > SOAR Settings > Advanced > IdP Group Mapping.
3. Click Add IdP Group.
4. Fill out dialog as follows. IdP Group = Security Analysts. Permission Group = Admin, SOC Role = Admin. Environment = leave blank.
5. Fill out another dialog as follows. IdP Group = SOC Engineers. Permission Group = Admin, SOC Role = Admin. Environment = leave blank.
6. Fill out another dialog as follows: IdP Group = NOC Engineers. Permission Group = Basic SOC Role = Tier 2. Environment = leave blank.
7. Fill out another dialog as follows: IdP Group = London. Permission Group = leave blank. SOC Role = leave blank. Environment = London.
8. Fill out another dialog as follows: IdP Group = Manchester. Permission Group = leave blank. SOC Role = leave blank. Environment = Manchester.

For customers using the Case Federation feature, see Case Federation for Google SecOps.