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.

Schedule a security validation action

You can automatically re-run successful actions on a recurring basis using the scheduling feature. It enables continuous security posture monitoring without manual intervention.

Create a schedule

To create a schedule from an existing execution, do the following:

1. Sign in to Google SecOps.

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

3. Click the Execution ID of an execution and click Create schedule.

4. Optional: In the Create schedule window, give the schedule a name and specify the schedule.

   If you don't enter a schedule name, the schedule is referenced by a schedule ID.

5. Click Create.

   The schedule runs using the latest versions of the action and execution context. However, these runtime variable values remain fixed and apply to every run of this schedule, regardless of any later updates to the action's defaults or the execution context.

6. Configure the schedule settings.

   You can either run a schedule at specific times or run it every hour.

   To run the schedule at specific times, do the following:

   1. In the Time dropdown, select Run at specific time.

   2. Specify the time of day in the adjacent text box.

   3. In the Days option, select one of the following:

      • Daily: Runs every day at the specified time.

      • Days of the week: Runs only on selected days (for example, Mon, Wed, Fri) at the specified time.

      • Day of the month: Runs once a month on the specified day (for example, the 15th) at the specified time.

      1. In the Months dropdown, select either Monthly (to run every month) or Specific Months to specify the exact months when the schedule should run (for example, January, April, July).

      2. In the Time zone dropdown, select the required time zone. This field defaults to the time zone set in your User Preferences (which may differ from your browser settings). To find or change this default setting, navigate to Profile > User Preferences > Localization > Time Zone.

      3. Click Create to create the schedule.

   To run the schedule at hourly intervals, do the following:

   1. In the Time dropdown, select Repeat hourly.

   2. Specify the frequency in the adjacent text box by entering the number of hours for the schedule cycle (for example, enter 2 to run every two hours).

   3. In the Hours option, select one of the following:

      • All hours of the day: The schedule will run around the clock, every hour of the day, based on the specified frequency.

      • Start and end hour: The schedule will run only within the specified starting and ending hour range (for example, between 8:00 AM and 5:00 PM).

   4. In the Days option, select one of the following:

      • Daily: Runs every day at the specified time.

      • Days of the week: Runs only on selected days (for example, Mon, Wed, Fri) at the specified time.

      • Day of the month: Runs once a month on the specified day (for example, the 15th) at the specified time.

   5. In the Months dropdown, select either Monthly (to run every month) or Specific Months to specify the exact months when the schedule should run (for example, January, April, July).

   6. In the Time zone dropdown, select the required time zone. This field defaults to the time zone set in your User Preferences (which may differ from your browser settings). To find or change this default setting, navigate to Profile > User Preferences > Localization > Time Zone.

   7. Click Create to create the schedule.

Schedule Examples

Configuration	When it runs
Time: Run at specific time (10:00 PM) Days: Days of the week (Monday) Months: Monthly Timezone: EST	Runs every Monday at 10:00 PM Eastern Standard Time.
Time: Run at specific time (01:00 AM) Days: Day of the month (1) Months: Specify (Jan, Apr, Jul, Oct) Timezone: PST	Runs at 1:00 AM Pacific Standard Time on the first day of January, April, July, and October.
Time: Run at specific time (12:00 AM) Days: Daily Months: Monthly Timezone: UTC	Runs every day at midnight (12:00 AM) Coordinated Universal Time.
Time: Run at specific time (09:30 AM) Days: Day of the month (15) Months: Specify (Feb, Apr, Jun, Aug, Oct, Dec) Timezone: EST	Runs at 9:30 AM Eastern Standard Time on the 15th of every second month (February, April, June, August, October, December).
Time: Repeat hourly Interval: Every 1 hour Hours: All hours	Runs non-stop. Executes precisely at the start of every hour, 24 hours a day (for example, 1:00 AM, 2:00 AM, 3:00 AM, and so on).
Time: Repeat hourly Interval: Every 4 hours Hours: Start and end hour (10:00 PM to 6:00 AM)	Runs overnight only. Executes at 10:00 PM, 2:00 AM, and 6:00 AM to capture server status during low-traffic periods.

Modify a schedule

You can modify the schedules you have created from the Schedules page. The Schedules table lists the following:

• Schedule name

• User that created the schedule

• Corresponding execution context

• Repeat time

• Next scheduled run

• When the execution last ran

To modify a schedule, do the following:

1. Click Security Validation and go to the Schedules tab.

2. Click the menu from the schedule that you want to modify.

3. Click Edit schedule of an execution and modify the values as needed.

4. Click Save.

Delete a schedule

To delete a schedule, do the following:

1. Click Security Validation and go to the Schedules tab.

2. Click the menu from the schedule that you want to delete.

3. Click Delete schedule.

4. Click Confirm.

The schedule is deleted.

Review schedule results

To view all executions of a schedule, do the following:

1. Click Security Validation and go to the Schedules tab.

2. Click the menu from the schedule.

3. Click View all results. The Execution history page appears.

The executions are filtered to display all executions associated with that specific schedule.

View last run results

To view the last run results of a schedule, do the following:

1. Click Security Validation and go to the Schedules tab.

2. Click the menu from the schedule.

3. Click View last run results to open the Execution details.

The system displays the details of the most recent execution that ran for that schedule.

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.