Add a new user to the Google Security Operations SOAR platform - SOAR only

Supported in:

SOAR

1. Navigate to Settings > Organization > User Management.
2. Click Add.
3. Fill out the relevant information. Everything in the drop-down fields can be edited after user creation. The Login ID field should contain an email address for internal users. If you edit the Login ID field the user is in pending status until they relog in with their new credentials.
   Note: If you are configuring new users for SAML authentication, make sure to select the required SAML provider in the User Type field and fill out the Login ID field according to the SAML specifications. The Email field for SAML/LDAP users is for notification purposes.

   

   Note:If you've selected a permission group which has edit permissions to All Environments this will appear here. To change this at permission group level, select None for All Environments in the Permissions page. After you make this change in the Permissions page, you can select one to several environments for the user to have access to.
4. Click Add. The new user appears in the list of users.
5. An email invitation is sent automatically to the user. For internal users, the status remains as "Pending" until they accept the email invitation to join Google Security Operations SOAR and create a password.
   The password link is valid for 3 days for an internal user. After that period, the admin can click Send Invitation in the User Management page to send the user a new link.
   For SAML users the status remains as "Pending" until the first time they login. They can log in directly to the platform; they don't necessarily need to log in through the mail invitation.
   

   

6. Click the picture icon to upload a PNG file that is no larger than 400kb for this new user.

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.

For more information on how these control access parameters work together, see Control access to the platform.

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.

Map users with multiple control access parameters

You can map each user with multiple permission groups, SOC roles and environments. This section describes the algorithms that the platform uses to apply multiple permissions for users.

Permission groups

You can map each user with a maximum of 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 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. In other words, if the user is mapped with several permission groups but only assigned a restricted action in one of those permission groups, they won't be restricted.

SOC roles

You can map each user 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 displaying all the widgets is if one SOC role includes another SOC role, then 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.