Tuesday's Tip of the Week - RBAC in Google SecOps: IAM Roles, Data Scopes, and Least Privilege

Tuesday 11/3/2026

Audience: SOC leads, analysts, and SecOps admins who control access to Google SecOps but haven’t used Google Cloud IAM before.

Summary: Google SecOps manages most access in Google Cloud IAM rather than in its own user screens. IAM is the same access system that controls every Google Cloud service. This brief covers the IAM basics you need, the SecOps roles that exist, and how to set up common access patterns, such as limiting CrowdStrike and Defender logs to one team.

1. IAM basics

IAM answers one question: who can do what, and where.

Two rules explain most access problems:

• Access adds up. A user gets every permission from every role they hold. Granting someone a smaller role doesn’t take anything away. You have to remove the bigger role.
• A grant without a condition always wins over the same role granted with a condition.

Where to grant access: in the Google Cloud console, select the SecOps project, then go to IAM & Admin > IAM > Grant access. Enter the principal, choose the role, add a condition if you need one, and save.

How your people appear in IAM:

Always grant roles to groups. Adding or removing a person then happens in your identity provider, and IAM doesn’t need to change.

2. How SecOps uses IAM

A scope is a saved filter on your data. It’s built from labels such as log type (CS_EDR), namespace, or an ingestion label you add to a feed (region=emea). Users with a scope see only the data that matches it. Users with no scope are called global users, and they see everything.

3. The SecOps roles

Watch for:

• Viewer, Editor, and Admin include permission to see all data. A scoped user who also holds one of them without a condition sees everything.
• The project-wide roles Owner and Editor also include SecOps permissions. Check who holds them on the SecOps project.
• SOAR moves to IAM when an admin selects Enable IAM on the SOAR IAM Migration tab. After that, Chronicle API Editor includes SOAR permissions, so review who holds it before you switch. The legacy SOAR API stops working after March 31, 2027.

4. Matching roles to jobs

To build a custom role:

1. Go to IAM & Admin > Roles.
2. Select the role to start from, for example Chronicle API Viewer, and choose Create role from selection.
3. Give the new role an ID that starts with secops.
4. Add the permissions you need. For Tier 1, add chronicle.cases.update and chronicle.cases.close.
5. Save. The new role now appears in the role list on the Grant access screen.

5. Use cases

5.1 Only the EDR team can see CrowdStrike and Defender logs

1. Create two scopes in Settings > SIEM Settings > Data Access > Scopes:
   • edr-team: allow the log types CS_EDR, CS_ALERTS, CS_DETECTS, MICROSOFT_DEFENDER_ENDPOINT, and any other CrowdStrike or Defender log types you ingest.
   • soc-general: allow all, then deny the same log types. Use Test scope to confirm that EDR events don’t appear.
2. Bind your rules to the scopes with Bind to scope in the Rules Editor. CrowdStrike and Defender rules go to edr-team, and all other rules go to soc-general. Do this before you turn on data RBAC. Otherwise every existing rule becomes global, and only global users can see its detections.
3. Grant the EDR group access. On IAM > Grant access, give the EDR group Chronicle API Restricted Data Access and Chronicle API Restricted Data Access Viewer. On Restricted Data Access, click Add IAM condition, open the condition editor, and paste:
   resource.name.endsWith('/edr-team') || resource.name.endsWith('/soc-general')
4. Grant everyone else access. Give them the same two roles with the condition resource.name.endsWith('/soc-general'). Then remove any Viewer, Editor, Owner, or Editor (project) grants they hold without a condition. Because access adds up, those grants would still show them everything.
5. Route the cases. In SOAR settings > Access Management > Environments, map edr-team to an EDR environment so that CrowdStrike and Defender cases appear only to the EDR team. This is a Pre-GA feature.

What to expect:

• Admins and other global users still see EDR data, so keep that group small.
• A rule that combines EDR data with other sources has to stay global, and only global users see its detections.
• Scoped users can’t see curated detections.
• Case search isn’t filtered by scope.

5.2 Regional SOCs (EMEA and Americas)

1. Add an ingestion label such as region=emea or region=amer to every feed and collector.
2. Create one scope per region that allows its label.
3. Grant each regional group Restricted Data Access with a condition for its scope, and map each scope to that region’s SOAR environment.
4. Logs that arrive without a label are visible only to global users, so add the label to every new feed.

5.3 Executive and HR-sensitive data

1. Create a custom label from a UDM query that matches the sensitive data, such as executive hostnames or user accounts.
2. Allow that label in an insider-risk scope, and deny it in soc-general.
3. Grant insider-risk only to the investigations team.
4. Users whose scope includes a custom label lose ingestion metrics, so their ingestion dashboards will be empty.

5.4 A contractor with an end date

1. Grant Chronicle API Limited Viewer to a contractor group. Limited Viewer can search but can’t see your rules.
2. Add a condition so the access ends automatically: request.time < timestamp("2026-12-31T00:00:00Z").
3. If they should see only part of the data, use Restricted Data Access with a scope instead. Limited Viewer can see all data.

6. Monitor Access Changes

Every IAM change in Google Cloud writes an audit log entry called SetIamPolicy. If you send the SecOps project’s audit logs into SecOps (log type GCP_CLOUDAUDIT), this rule alerts on any grant or removal of a SecOps role:

rule secops_project_access_change {
  meta:
    description = "IAM binding change on a Chronicle or secops custom role"
    severity = "Medium"
  events:
    $e.metadata.log_type = "GCP_CLOUDAUDIT"
    $e.metadata.product_event_type = "SetIamPolicy"
    $e.target.resource.attribute.labels["ser_binding_deltas_role"] = /chronicle|secops/ nocase
  outcome:
    $actor = $e.principal.user.userid
    $action = $e.target.resource.attribute.labels["ser_binding_deltas_action"]
    $member = $e.target.resource.attribute.labels["ser_binding_deltas_member"]
  condition:
    $e
}

7. Action items

• Open IAM & Admin > IAM on the SecOps project and list everyone with a Chronicle role, plus anyone with Owner or Editor.
• Create an identity provider group for each job in section 4.
• Build the Tier 1 and playbook developer custom roles.
• Replace grants to individual users with grants to groups.
• Design your scopes and bind every rule to one before turning on data RBAC.
• Deploy the access change rule and test it with a test grant.