Control access to platform using SOC roles, environments, and permission groups

Supported in:

This document discusses access for different users to various modules in the platform, with a special emphasis on who gets to see the cases. Access is based on three separate mechanisms that work together to provide or restrict access to different parts of the platform. These mechanisms are SOC roles, environments, and permission groups.

SOC roles

Conventionally, different access rights are assigned to different SOC roles, but within your organization, you can experiment with the permission levels and environments to determine the full scope of responsibility for each user group in the Google Security Operations platform. The Google Security Operations platform comes with predefined SOC roles but customized roles can be added. The predefined SOC roles are defined as follows:

  • Tier 1: performs basic triage on the alerts
  • Tier 2: reviews high priority security threats
  • Tier 3: handles major incidents
  • SocManager: manages the SOC team
  • CISO: top level manager within your organization
  • Administrator: has access to the entire Google Security Operations platform

One of these SOC roles is used as a default role to be automatically assigned to incoming cases. Each SOC role also has additional SOC roles attached to it and therefore can monitor all cases belonging to these additional roles. So, for example, Tier 1 analysts will see cases assigned to Tier 1 SOC roles plus their other additional roles.

After a case has been created in the platform it can then be reassigned from the default SOC role to a specific SOC role or even to an individual user either manually or by a playbook automated action. By assigning a case to a SOC role, you can be sure that a group of people are aware of the case and then after an analyst assigns it to themselves, it provides an indication that they are handling it.

Environments

You can define different environments to create data segregation. This ensures a logical separation between the majority of the platform modules such as cases, playbooks, ingestion, and dashboards. This is relevant if you are an enterprise company and have separate business units where it makes sense to divide them up into different environments with different automation processes, settings, and more. For MSSPs who have many different end customers, each environment can represent a separate customer.

You can experiment with the platform configuration settings so that only analysts that are associated with a specific environment will see cases from that environment. Other examples include configuring the playbooks module for several environments. The default environment is the baseline of the platform and is used when no other environments have been defined or selected. In addition, platform admins have access to all environments, including future environments added to the platform.

Permission groups

The Google Security Operations SOAR platform comes with predefined permission groups but more can always be added. The predefined groups are:

  • Admin
  • Basic
  • Readers
  • View Only
  • Collaborators
  • Managed
  • Managed-Plus

The permission groups decide the level of access each group has to different modules and settings in the platform. The settings are on a granular level. For example, on the top level you can enable access to the reports module for a particular permission group. On the next level down, you can enable access just to view the advanced reports. On the bottom level, you can let users edit the advanced reports.

How SOC roles, environments, and permission groups work together

This section demonstrates the relationship of these features by focusing on an example of a mid-sized bank with a geographical location in Scotland and one in England. You want the Tier 1 SOC role to triage incoming cases but escalate to Tier 2 if deeper investigation is required. You can set this up with the following procedure.

Set up different permission groups with the following steps:

  1. In the Environments page, create two new environments and call them Scotland branch and England branch.
  2. In the Roles page, create two new SOC roles, Tier 1 Scotland and Tier 2 England.
  3. In the Tier 2 England role, make sure to add Tier 1 Scotland role to their additional roles. Define Tier 1 as the default role.
  4. In the Permissions page, create two new permission groups and call them Tier 1 Scotland and Tier 2 England.
  5. For the Tier 1 permissions group, make sure to disable IDE and playbooks but allow them full editing rights on the cases module.
  6. For the Tier 2 permissions group, make sure to enable the IDE and playbooks with full editing rights for both modules.
  7. For Google Security Operations SOAR only platform users, create new users in the User Management page and make sure to select the required environment, SOC role, and permission group that you created earlier.
  8. For Google SecOps platform users, create two new IdP groups in the IdP Mapping page and make sure to select the environment, SOC role, and permission group that you created earlier.
  9. For Security Command Center Enterprise, create two new IAM roles in the IAM roles page and make sure to select the environment, SOC role, and permission group that you created earlier.

Now, when a case is created on the platform. Tier 1 will be able to triage it and if necessary, reassign it to Tier 2 if it requires deeper investigation or modification of playbooks or actions.

The SOC roles, permission groups, and environments are mapped onto different IdP groups, or user groups, depending on which product you have bought. For more information on mapping users in the platform:

For Google SecOps customers, refer to: Provision, authenticate, and map users in the Google SecOps platform. For Google SecOps SOAR customers: refer to: Add users to the platform.