Security Validation in Google Security Operations

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 SecOps Technical Support Service guidelines and the Google SecOps Service Specific Terms.

Google Security Operations Security Validation enables you to proactively test your security by simulating attacks in your Google Cloud environment. Continuous operation of Security Validation reduces risk by ensuring that your configurations and controls are responding to the latest threats and operating as expected.

Security Validation uses actions—scripts that mimic attacker techniques in your Google Cloud projects. These actions produce events designed to trigger detection alerts and help you verify that your security policies, settings, and detection rules are working as expected.

Plan your implementation

Make sure you have the following setup:

• Your tenant must have Security Validation enabled.

• Security Validation only works with self-managed projects.

• You need one or two Google Cloud projects. While you can use the same project for both executing and targeting, we recommend using separate projects for better security, keeping your tests clean, and making it easier to manage your setup.

  • Execution project: Security Validation runs your security tests in the execution project. It uses Cloud Run and Cloud Storage to do this. These jobs and buckets are only intended to be used by the validation service. Other users should not be granted access to them.

    The Cloud Run API, Resource Manager API, and IAM API must be enabled in this project and you must have the resourcemanager.projects.SetIamPolicy, storage.buckets.SetIamPolicy, storage.buckets.create, and storage.buckets.delete permissions in order to create a security validation context for it. See IAM permissions reference for the list of roles that provide this permission.

  • Target project: where the API calls made by the security validation action script operate. The success of actions depends on whether the required APIs used by the actions are enabled in this project and whether the service accounts in the security validation context have the necessary permissions on them.

• Service accounts: requires one or more service accounts in the execution project. These accounts execute the action scripts. Any user who needs to run an action with a specific context, must have the iam.serviceAccounts.actAs permission on the service account(s) in that context.

Sample implementation

Consider an example of the Generate access token using signJWT permission action. This example assumes that you have already set up a security validation context and are running the action within that context. The action is expected to generate Cloud Audit Logs and trigger the Access token generation with signJWT threat detection rule.

The following setup is required:

• Enabled APIs: the Identity and Access Management (IAM) service account credentials API must be enabled in both the target and execution projects.

• Service account permissions: the service account specified in the profile field of the security validation context must have the iam.serviceAccounts.signJwt permission in the target project. This can be granted through the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator). This role can be granted either on the project or the target service account (which, for this action, is the default compute engine service account of the target project).

• IAM audit logging: IAM audit logging (ADMIN_READ) must be enabled in the target project to capture the events generated by this action.

• Custom export filter: to ingest the events generated by this action through SecOps Google Cloud ingestion, a custom export filter must be set that includes log_id("cloudaudit.googleapis.com/data_access").

• Rule set: the Cloud Threats -> [Google Cloud] IAM Abuse rule set must be enabled and set to alerting to see detections in the search and investigation view.

Required permissions

To use the Security Validation feature, you need to be assigned a role that provides Security Validation permissions in your Google SecOps instance project.

The predefined roles chronicle.viewer, chronicle.editor, and chronicle.admin provide the following permissions:

• chronicle.viewer - Read-only access to get and list Security Validation action, context, job, and execution resources.
• chronicle.editor - Includes all viewer permissions, plus the ability to create, update, and delete Security Validation contexts and jobs, and to run Security Validation jobs.
• chronicle.admin - Includes all editor permissions, plus the ability to create, update, and delete custom Security Validation actions (currently API only).

If you're not using the Chronicle predefined roles listed above, you can grant equivalent permissions using a custom role or by assigning the chronicle.securityValidationAdmin role, which includes the same Security Validation permissions as chronicle.admin. Note: the chronicle.securityValidationAdmin role is currently not visible in the Google Cloud Console UI and must be assigned using the gcloud CLI tool.

For more information, see Required roles.

Create a security validation context

A security validation context sets up the environment for your security tests. It specifies which project to use, which account to run the test with, and any other details that your actions need. You can reuse the same context for different actions.

To create a security validation context, do the following:

1. Sign in to Google SecOps.

2. Click Security Validation and go to the Execution Contexts tab.

3. Click Add Execution Context.

4. In the Add Execution Context dialog, do the following:

   1. In Basic Properties, enter the context name and description, and click Next.

   2. In Environment Settings, enter the Google Cloud project ID, the execution service account, and the cleanup service account. Click Next.

      We recommend using separate service accounts for action profile (to execute action scripts) and for setup/cleanup profile (to execute the setup and cleanup scripts that are part of some actions). These service accounts can be given different permissions in the target project.

   3. In Runtime Variables, add one or multiple variables to dynamically override default parameters. Add key-value pairs where the key is the parameter name and the value is its override value.

      Tip: All actions require the TARGET_PROJECT_ID variable to specify the Google Cloud project that you want to target.

   4. Click Save.

Note: Creating a context allows Google SecOps to create Cloud Run jobs and Cloud Storage buckets in the specified project. Resource and service charges related to these workloads are charged according to the project billing settings.

Run security validation action

To run a security validation action for a security validation context, do the following:

1. Sign in to Google SecOps.

2. Click Security Validation and go to the Content Library tab.

3. Select an action and click Run.

4. On the dialog, select the execution context that you created and click Run Now.

A new execution is created and appears on the Execution History tab.

Review execution results

You can view the security validation action you execute in the Execution History tab. To review the execution results, do the following:

1. Sign in to Google SecOps.

2. Click Security Validation and go to the Execution History tab to monitor the execution status.

   The Run status column indicates whether the execution was successful or encountered an error. If successful, you can view the generated events and detections triggered by the security validation action in Google SecOps.

3. Click the execution ID to view the execution details.

The Action Execution Details page provides the status, outcome, and in-depth analysis of a validation action. Use this page to validate your security posture by understanding which detection rules the action's activity triggered.

Correlation progress shows the real-time correlation workflow progress for an execution. While correlation runs, the total event count might increase until the task finishes.

Note: Click refresh Refresh to reload the table data or reload the page to update the total event count.

Analyze the Correlated Rules table

The Correlated Rules table lists detection rules triggered during the action's execution, including both custom and curated rules.

The table displays both custom and curated rules. It includes two groups: * Rules explicitly defined in the action's metadata * Additional rules triggered by correlated events

This helps you identify which rules performed as expected and which rules might require further investigation.

The table includes the following columns:

• Rule name: name of the detection rule. Click the rule name to view the rule definition and its detection history.

• Detection count: number of detections triggered by the rule. A value of 0 indicates no matching events were found.

• Detections: link to the Detections page that displays triggered detections from this run.

• Associated with Action: indicates whether the rule was part of the action's metadata:

  • Yes: the action's metadata includes the rule. The system expects it to trigger when the action executes.

  • No: this action's metadata does not include the rule, but its logic matched the generated events and triggered it.

This table helps you identify the outcomes:

Associated to Action column	Detection count column	What it means
YES	1 or more	Success: An expected rule successfully triggered one or more detections.
NO	1 or more	An unexpected rule was triggered by the activity.
YES	0	An expected rule failed to trigger any detections.

Analyze correlated events

After you run a security validation action, use the correlated events to assess how your environment and security controls responded to the simulated threat.

Your analysis includes two components: a real-time status of the correlation workflow and a detailed table of all the generated events.

The Event Correlation Status shows the current workflow state as one of the following:

• Running: the system is actively searching for correlated events.

• Completed: all event correlation activities have completed successfully.

• Errored: the correlation workflow encountered an error and could not complete.

The Correlation workflow complete at indicates a time estimation of when the correlation is expected to or has completed.

The Events table lists all all events generated by the action. Use this data to analyze individual responses in your environment and security controls.

The table includes the following columns:

• Event: event ID. Click to view event details in UDM Search.

• Event timestamp: time the event occurred on the source system (for example, the server or the firewall).

• Observed timestamp: time the security validation service found and correlated the event with the execution.

• Product: product that generated the event.

• Security result action: outcome of the event (Blocked or Not blocked), based on the security_result.action field of the UDM event.

Actions may target regions outside of the Google SecOps instance where they're run. Execution results display logs retrieved from the execution project.

Troubleshooting

Failed to create cloud run job for primary principal of context: permission 'iam.serviceaccounts.actAs' denied

You encounter an IAM permission error when running a security validation action that is similar to the following:

Failed to run job: failed to create cloud run job for primary principal of
context <context_name>: error in cloud run jobs.CreateJob:
generic::permission_denied: com.google.cloud.eventprocessing.serverless.error.MissingServiceAccountPermissionsException: userFacingMessage: Permission
'iam.serviceaccounts.actAs' denied on service account <service_account_name>

Recommended actions

• Wait for IAM propagation: if you created or updated the context just before running the action, wait a few minutes and try again. IAM changes are eventually consistent, and it can take time for role assignments to propagate across the system.

• Verify permissions: verify that the identity running the action has the iam.serviceaccounts.actAs permission on the specified service account.

For more details, see Access change propagation in IAM.