Google Chronicle
Overview
Google Chronicle — now part of Google SecOps — can ingest events over a plain HTTPS webhook. Britive can push its audit log to any HTTPS URL through a webhook notification medium. Pointing one at the other gives you a live feed of Britive audit activity in Chronicle with nothing to install and no compute to run or pay for on either side.
What you’ll accomplish:
- Create an HTTPS webhook feed in Google Chronicle and its authentication credentials
- Configure a webhook notification medium in Britive pointed at that feed
- Attach the notification medium to Britive’s audit log so matching events are forwarded automatically
- Confirm events are arriving in Chronicle
There is no published Chronicle parser for Britive’s audit log format. This guide gets raw Britive audit JSON into Chronicle under a generic log type. Turning those raw fields into Chronicle’s Unified Data Model (UDM) requires a custom parser, which is outside the scope of this guide — see Field Mapping and Normalization.
Prerequisites
Before you begin, make sure you have:
- A Britive tenant with System admin access (to configure notification mediums and audit log webhooks)
- A Google Cloud project with Google SecOps configured and the Chronicle API enabled, linked to Google Cloud services
- Permission to create Feeds in Google SecOps and API keys in the Google Cloud console
Never hardcode the Chronicle secret key or API key in code or commit them to a repository. Britive stores request headers as part of the notification medium configuration — treat that configuration with the same care as any other credential store.
How It Works
graph LR
A["Britive Audit Log"] -->|"event matches<br/>filter expression"| B["Webhook<br/>Notification Medium"]
B -->|"HTTPS POST<br/>+ auth headers"| C["Chronicle<br/>HTTPS webhook feed"]
C --> D["Raw log<br/>(generic log type)"]
D -.->|"custom parser<br/>(not included)"| E["UDM"]
| Stage | What happens |
|---|---|
| Filter | Britive evaluates every audit event against the filter expression on the audit log webhook |
| Forward | A matching event is POSTed as JSON to the URL configured on the webhook notification medium, with any configured headers attached |
| Authenticate | Chronicle’s feed endpoint expects its own API key and secret key as headers (or query parameters) on every request |
| Ingest | Chronicle stores the request body as a raw log under the log type you chose when creating the feed |
| Normalize (not covered here) | A parser maps raw fields into UDM so the event is usable by Chronicle rules and searches |
Britive’s webhook notification medium is a single configurable destination — a URL plus optional headers. The same medium type is used both for approval notifications and, once attached under Manage Webhooks, for audit log forwarding. This guide only uses it for audit log forwarding.
Configure the Webhook Feed in Google Chronicle
Do this first — Britive needs the feed’s endpoint URL and secret key before you can finish its side of the configuration.
Create the feed
In the Google SecOps console, go to Settings → Feeds → Add new. Enter a Feed name (for example Britive Audit Log), and set Source type to Webhook.
Choose a log type
Select a Log type for the feed. Chronicle does not publish a Britive-specific parser, so pick a generic option intended for raw or unstructured JSON (check your Chronicle log type catalog for the current name — this varies by Chronicle release). Click Next.
Set optional parameters
Optionally set:
| Parameter | Value |
|---|---|
| Split delimiter | Leave unset unless you plan to batch multiple newline-separated JSON events per request |
| Asset namespace | Your Chronicle asset namespace, if you use one |
| Ingestion labels | A label such as britive to tag every event from this feed |
Click Next, review the summary on the Finalize screen, then click Submit.
Generate the secret key
Click Generate Secret Key. Copy it immediately and store it in your secret manager — Chronicle will not show it again. Generating a new key invalidates the old one.
Copy the endpoint URL
Open the Details tab and copy the value in Endpoint Information. This is the URL you’ll enter as the Britive webhook notification medium’s destination.
Confirm the feed is enabled
The Feed Enabled toggle is on by default — leave it on unless you want to stage the configuration before Britive starts sending events. Click Done.
Create a Chronicle API Key
Open Credentials in the Google Cloud console
Go to the Credentials page for the project your Chronicle instance uses.
Create the key
Click Create credentials → API key.
Restrict the key
Restrict the key’s access to the Chronicle API so it can’t be reused against unrelated Google Cloud services.
You now have everything Chronicle requires per request:
X-goog-api-key: API_KEY
X-Webhook-Access-Key: SECRETIf your destination doesn’t support custom headers, Chronicle also accepts the credentials as query parameters on the endpoint URL: ENDPOINT_URL?key=API_KEY&secret=SECRET. Britive’s webhook notification medium supports custom headers, so use the header form in this guide — it keeps both values out of logs that record request URLs.
Configure the Webhook Notification Medium in Britive
Open Notification Mediums
Log in to Britive with administrator privileges and go to System admin → Global Settings → Notification Mediums.
Add a medium
Click Add Medium. Enter a Name (for example Google Chronicle) and an optional Description.
Select Webhook
From the application drop-down, select Webhook. Enter the Chronicle feed’s Endpoint Information URL (from Copy the endpoint URL) as the Webhook URL.
Add the authentication headers
Under request headers, add both:
| Header | Value |
|---|---|
X-goog-api-key | The Chronicle API key |
X-Webhook-Access-Key | The Chronicle feed’s secret key |
Save
Click Save. This medium is now available to attach to the audit log.
Forward Audit Logs to the Webhook
Open Manage Webhooks
Go to System admin → Audit Log → Manage Webhooks.
Add the webhook
Click Add Webhook. Select the Google Chronicle notification medium you just created.
Set the filter expression
Enter a filter expression to control which audit events are forwarded. An empty filter forwards everything — the right starting point until you know what volume you’re dealing with.
Britive’s docs confirm the Audit Log Advanced Search UI uses STARTS WITH, NOT EQUALS, CONTAINS, and EQUALS operators combined with and, but don’t spell out the exact typed syntax for this filter expression field. The examples below use the field operator value syntax (eq, neq, co, sw, combined with and) that’s confirmed elsewhere in Britive’s audit log tooling — verify against your own tenant’s UI before relying on it, since this screen may expect a different form.
| Filter | Keeps |
|---|---|
event.eventType sw access. | Privileged access events only — access.checkout, access.checkin, and that family |
event.eventType sw secret. | Secret reads, writes, and deletions |
result.success eq false | Failed actions only |
event.eventType neq environment.scan | Everything except routine environment scans |
Save
Click Save. Britive starts evaluating new audit events against this filter immediately — there is no backfill of events that occurred before the webhook was added.
Field Mapping and Normalization
Britive’s audit record carries the same five top-level groups documented for the Audit Log and used throughout Recommended Alerts: actor, client, event, target, and result. The webhook is not separately documented to emit a different shape, so treat that structure as the starting point — but capture and inspect a real payload from your feed before building a parser, since the exact JSON your tenant sends over this specific channel hasn’t been independently confirmed against a live payload for this guide.
Because Chronicle has no built-in Britive parser, the raw JSON lands as an unparsed log under the log type you chose. To make it usable in Chronicle searches, rules, and dashboards, you’ll need to either:
- Write a custom Chronicle parser (or parser extension) that maps Britive’s
actor/client/event/target/resultfields into UDM, or - Query the raw log fields directly where your Chronicle log type supports it, without a full UDM mapping
Both are outside the scope of this guide. If you need the parser built, contact Britive Customer Success or Google Chronicle support.
Verify
Confirm the feed accepts requests
Test the Chronicle endpoint directly before waiting on a real Britive event:
curl --location 'ENDPOINT_URL' \
--header 'Content-Type: application/json' \
--header 'X-goog-api-key: API_KEY' \
--header 'X-Webhook-Access-Key: SECRET' \
--data '{"test": "britive-chronicle-webhook-check"}' \
--failA successful call returns no output and exit code 0:
echo $?This test payload is only to confirm the feed accepts authenticated requests — it isn’t the shape of a real Britive audit event, and Chronicle will still store it as an unparsed raw log.
Generate a real Britive event
Perform an action in Britive that matches your filter — for example, check out a profile if your filter includes event.eventType sw access..
Confirm it arrived in Chronicle
In Google SecOps, open the feed’s details and check its ingestion status, or search the raw logs for the log type and ingestion label you set when creating the feed.
Troubleshoot
| Symptom | Likely Cause | Fix |
|---|---|---|
| Chronicle feed shows no events | Britive webhook not attached, or filter matches nothing | Confirm the notification medium is selected under Manage Webhooks and that the filter expression is correct — start with an empty filter to rule it out |
| Chronicle returns 401/403 | Missing or incorrect X-goog-api-key / X-Webhook-Access-Key headers | Re-check both header names and values on the Britive notification medium; regenerate the Chronicle secret key if you’re unsure it was copied correctly |
| Chronicle request fails with 413 or throttling | Batch of events per request larger than 4 MB, or above 15K QPS for the instance | Britive sends one event per request by default — if you introduced batching, reduce batch size |
| Events arrive but appear as raw/unparsed | No Chronicle parser exists for Britive’s JSON shape | Expected without a custom parser — see Field Mapping and Normalization |
| Notification medium can’t be selected under Manage Webhooks | Medium wasn’t saved as type Webhook, or wasn’t saved at all | Re-check the medium under Global Settings → Notification Mediums |
| Secret key no longer works | A new secret key was generated, invalidating the old one | Update the X-Webhook-Access-Key header on the Britive notification medium with the current secret |