Integrating Cato Data with Google SecOps

Prev Next

Important: This integration is a preview and subject to change. The certification process is underway.

Overview

Use the Google SecOps integration to analyze Cato network and security data alongside other security telemetry in Google Security Operations (Google SecOps, formerly Chronicle). The native integration pushes data directly to a Google SecOps HTTPS webhook feed for monitoring and investigation.

You configure the integration in the Cato Management Application (CMA). Cato sends newline-delimited JSON, with one record per line, and authenticates with a Google Cloud API key and the feed's webhook secret key.

This integration is separate from the Google Chronicle integration that retrieves data through the Cato eventsFeed API.

Google SecOps Data Sources

You can select Events, Flows, or both:

  • Events – Records of network and security activity, such as policy matches, threats, connectivity changes, and audit activity.

  • Flows – Network flow records that add application and user context and aggregated session details, such as bytes, packets, and duration.

Each record includes a data_source field with the value events or flows. Flow data can generate significantly more volume than event data, depending on your traffic.

Prerequisites

  • Editor permission for Integrations in the Resources section of the CMA. For more information, see Managing Admin Roles Using RBAC.

  • A Google SecOps instance linked to a Google Cloud project, with the Chronicle API enabled.

  • Permission to create a webhook feed in Google SecOps and an API key in the linked Google Cloud project.

  • The prerequisites described in Getting Started with Event Integrations, including any required IP allowlisting.

Use Cases

These examples assume that the relevant data sources are ingested and the fields used to correlate records are parsed consistently.

Events

After validating UDM mappings, create a YARA-L rule that correlates a suspicious sign-in with a Cato threat event for the same user within a defined time window.

Flows

Use statistical searches to identify unusually large outbound transfers, then examine associated Cato events for policy or threat context.

Creating the Google SecOps Integration

Create a webhook feed and a Google Cloud API key, test the endpoint with curl, then enter the feed URL and credentials in the CMA.

Step 1: Create the HTTPS Webhook Feed in Google SecOps

To create the webhook feed:

  1. Log in to Google SecOps and go to Settings > Feeds.

  2. Click Add new and enter a Feed name, such as Cato Networks.

  3. For Source type, select Webhook.

  4. Select the Log type for the Cato records.

  5. Click Next.

  6. Set Split delimiter to \n so that Google SecOps ingests each newline-delimited JSON record as a separate log entry.

  7. (Optionally) Configure an Asset namespace and Ingestion labels.

  8. Click Next, review the feed configuration, and click Submit.

  9. Click Generate Secret Key. Copy the key and store it securely before leaving the screen. Google does not display it again.

  10. On the Details tab, copy the feed endpoint URL from Endpoint Information. Use the complete URL, including the :importPushLogs suffix.

  11. Confirm that the feed is enabled.

Generating another secret key invalidates the previous key. If you rotate the secret after configuring Cato, update the Webhook Access Key in the CMA immediately to avoid a gap in delivery.

Step 2: Create the Google Cloud API Key

To create the API key:

  1. In the Google Cloud console, select the project linked to your Google SecOps instance.

  2. Go to APIs & Services > Credentials.

  3. Click Create credentials > API key.

  4. Restrict the key to the Chronicle API and save the restriction.

  5. Copy the API key and store it securely.

You can also use an existing API key restricted to the Chronicle API for the linked project.

Step 3: Test the Endpoint with curl

Before you configure the integration in the CMA, send a test request directly to Google SecOps. This helps isolate endpoint and authentication issues from the Cato integration.

To test the endpoint:

  1. Replace ENDPOINT_URL with the complete feed endpoint URL from Step 1. When prompted, enter the Google Cloud API key from Step 2 and the feed's secret key from Step 1.

  2. Update the sample timestamps to the current UTC time, then run the following command. Keep each JSON object on its own line; the command sends both records in one request:

    Run the entire example in an interactive Bash shell (run bash first if needed). Enter credentials at the hidden prompts; do not insert them into the command. The example disables shell tracing and passes authentication headers through standard input using --header @-, keeping credentials out of shell history and curl command-line arguments. The temporary credential variables are discarded when the example finishes.

    (
      set +axv
      set -euo pipefail
      unset CATO_TEST_API_KEY CATO_TEST_WEBHOOK_SECRET
      IFS= read -r -s -p 'Google Cloud API key: ' CATO_TEST_API_KEY
      builtin printf '\n' >&2
      case "$CATO_TEST_API_KEY" in
        ''|*$'\r'*) builtin printf 'Enter a nonempty credential without carriage returns.\n' >&2; exit 1 ;;
      esac
      IFS= read -r -s -p 'Webhook secret key: ' CATO_TEST_WEBHOOK_SECRET
      builtin printf '\n' >&2
      case "$CATO_TEST_WEBHOOK_SECRET" in
        ''|*$'\r'*) builtin printf 'Enter a nonempty credential without carriage returns.\n' >&2; exit 1 ;;
      esac
    
      builtin printf '%s\n' "X-goog-api-key: ${CATO_TEST_API_KEY}" "X-Webhook-Access-Key: ${CATO_TEST_WEBHOOK_SECRET}" | \
        curl -q --fail --show-error --include --max-time 30 -X POST "ENDPOINT_URL" \
      --header @- \
      -H "Content-Type: application/json" \
      --data-binary '{"message":"test event from Cato 1","timestamp":"2026-07-14T12:00:00Z"}
    {"message":"test event from Cato 2","timestamp":"2026-07-14T12:00:01Z"}'
    )
  3. Check the HTTP response for an error. A successful request returns an HTTP 2xx status.

  4. In Google SecOps, search recent raw logs for test event from Cato 1 and test event from Cato 2. Allow several minutes for ingestion, then confirm that they appear as two separate log entries. If both records appear in one log entry, check that the feed's Split delimiter is set to \n. This sample checks connectivity and record splitting; it does not validate all parser mappings for Cato Events and Flows.

This test checks whether the destination accepts the sample request and splits it into individual log entries. Verify Cato data and parsing after configuring the integration below.

Step 4: Create the Integration in the CMA

To create the Google SecOps integration:

  1. From the CMA navigation menu, go to Resources > Integrations.

  2. Open the Configured Integrations tab and click New.

  3. Select Google SecOps and the Data Export capability.

  4. Enter a Name and an optional Description.

  5. For Webhook URL, paste the complete feed endpoint URL from Step 1.

  6. For Google Cloud API Key, paste the API key restricted to the Chronicle API.

  7. For Webhook Access Key, paste the feed's secret key.

  8. Under Data Sources, select Events, Flows, or both.

  9. (Optionally) Configure event and flow filters to control which records are sent. See Filters.

  10. Click Save.

Cato stores both keys encrypted and does not display them again. When editing the integration, leave a key unchanged to keep its stored value, or enter a replacement.

Cato sets the X-goog-api-key, X-Webhook-Access-Key, and Content-Type: application/json headers automatically. You do not need to configure headers.

Step 5: Verify Ingestion and Parsing

To verify that Cato data arrives in Google SecOps:

  1. In the CMA, review the integration status. Refresh the page if needed and check for authentication or destination errors.

  2. In Google SecOps, go to Settings > Feeds, open the Cato feed, and review its status and last-ingestion time.

  3. Generate a recent Cato event or network traffic for each selected data source.

  4. Search recent raw logs using an ingestion label configured on the feed or a distinctive Cato record value. You can also search for the data_source field with the value events or flows. Allow several minutes for ingestion.

  5. Check that individual records are parsed and their timestamps and mapped fields match the Cato activity.

Filters

Use event and flow filters to limit the Cato data exported to Google SecOps. This helps control ingestion volume and focus investigations on relevant activity.

Filter conditions within a group use AND logic. Separate groups use OR logic.

  • Events Filter – Click Add Filter to define a condition, or Add Group to add another filter group.

  • Flows Filter – Available when Flows is selected. It uses the same grouping logic as the event filter.

Filters that are too restrictive can exclude all records without reporting an error. If no data arrives, check the selected data sources and filter conditions.

Known Limitations

  • Google SecOps supports a maximum webhook request size of 4 MB and a maximum throughput of 15,000 queries per second (QPS) per instance.

  • How Cato records map into UDM depends on the feed's Log type and parser configuration.

  • Regenerating the feed secret invalidates the previous key. Update the Webhook Access Key in the CMA when you rotate the secret.

  • You cannot customize the Cato integration's request body format, content type, or header names.

Troubleshooting

Issue

Solution

Authentication fails with HTTP 401 or 403

Check that the Google Cloud API key belongs to the linked project and permits the Chronicle API. Confirm that the feed secret has not been replaced, and update the credentials in the CMA if needed.

The destination is unreachable

Copy the complete feed endpoint URL from Details > Endpoint Information, including :importPushLogs, and confirm that the feed is enabled.

The integration appears healthy but no data arrives

Check data-source selection and filters, generate matching Cato activity, and review the feed's ingestion status and parser errors.

Only events or only flows arrive

Confirm that the required sources are selected and their filters allow matching records. Check that each source is sent to the feed configured for it.

Raw records arrive but fields are not parsed

Review the feed's Log type and parser configuration against the setup in Step 1.

Requests are rejected or ingestion is delayed at high volume

Review destination errors for request-size or throughput limits and contact Cato Support with the affected time range and error details, excluding API keys and webhook secrets.

Additional Resources