68 Detection engineering on exported logs

Caveats

• 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. 1. Confirm the audit-log export to BigQuery is on and the dataset is complete (this control consumes what audit-log-export №33 produces).
   open ↗

   

   https://admin.google.com/ac/reporting/bigqueryexport · captured 2026-07-15

   Reporting › Data integrations › BigQuery Export

   BigQuery export

   On

   dataset

   the one your rules query

2. 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

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

   Scheduled query cadence

   15min–1h depending on the rule

4. 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.