# 66 Detection engineering on exported logs

> v0.0.3 · role: Detect · edition: Ent/Edu/Frontline Std+, Ent Essentials Plus · [policy: #33 · #18](https://docs.google.com/spreadsheets/d/1nOztaPd1Y7eNeRSR_hdovYy-ncpx-bAx/edit?usp=sharing&ouid=115159875779023172526&rtpof=true&sd=true)

Scheduled Sigma rules or BigQuery SQL run over the exported audit logs ([31 Audit-log export to SIEM/BigQuery](audit-log-export.md)), one rule per hypothesis, version-controlled, each with a documented false-positive rate: an OAuth grant to a new client id, a domain-wide delegation change, a mass Drive download, an admin role grant, a forwarding rule added. These are the API-level attacks no console screen shows you, and the hits are routed into the same alert pipeline the heartbeat ([№52](alert-pipeline-heartbeat.md)) proves is alive.

Documentation: [About reporting logs and BigQuery](https://knowledge.workspace.google.com/admin/reports/about-reporting-logs-and-bigquery)

## Caveats

- Untested rules are worse than no rules — they create the belief in coverage that stops anyone looking, so test each against a replayed or synthesised event and keep the test as a regression.
- Export latency (activity log events land in BigQuery within about 10 minutes) makes this a detection, not a prevention — budget for the window in which the attacker is unobserved.
- BigQuery export requires Enterprise Standard+, Education Standard+, Frontline Standard+ or Enterprise Essentials Plus — on lower editions the export itself, and with it this entire control, is unavailable.

## Setup steps

1. Confirm the audit-log export to BigQuery is on and the dataset is complete (this control consumes what audit-log-export [№31](audit-log-export.md) produces). — `Reporting › Data integrations › BigQuery Export`

   - **BigQuery export** = On
   - **dataset** = the one your rules query

   docs: [Set up service log exports to BigQuery](https://knowledge.workspace.google.com/admin/reports/set-up-service-log-exports-to-bigquery)

2. Write detections as code: Sigma rules or scheduled BigQuery SQL over the exported activity tables — OAuth grant to a new client id, DWD change, mass Drive download, admin role grant, forwarding rule added.

   - **One rule** = one hypothesis, version-controlled, with a documented false-positive rate

   docs: [Example queries for reporting logs in BigQuery](https://knowledge.workspace.google.com/admin/reports/example-queries-for-reporting-logs-in-bigquery)

3. Schedule the queries and route hits into the same alert pipeline that alert-pipeline-heartbeat ([№52](alert-pipeline-heartbeat.md)) proves is alive.

   - **Scheduled query cadence** = 15min–1h depending on the rule

   docs: [Scheduling queries](https://docs.cloud.google.com/bigquery/docs/scheduling-queries)

4. Test each rule against a replayed or synthesised event before it goes live, and keep the test as a regression.

## Ongoing maintenance

- **[automatable: script]** Per schedule: the detection queries run against the exported logs.
- **[automatable: AI agent]** Monthly: tune rules against false-positive/negative feedback and new TTPs.

## How to verify

1. Replay a known-bad event pattern (e.g. a mass-download simulation from a test account) into the pipeline and confirm the detection fires end to end — the query alone proves nothing.

## Settings screens

- Reporting > Data integrations (BigQuery Export — the log source these rules run over)
  - console: https://admin.google.com/ac/reporting/bigqueryexport
  - screenshot: ../screenshots/admin.google.com/ac/reporting/bigqueryexport.png