Google Security Operations (Chronicle) Guide: UDM, YARA-L Detections and SOAR

Google Security Operations (Google SecOps, formerly Chronicle) holds a year or more of an organisation's security telemetry and the automation that acts on it, so its own identities, rules and feed credentials become some of the most sensitive in the estate. The platform combines a SIEM built on the Unified Data Model (UDM), YARA-L 2.0 detection rules, Google-maintained curated detections, a SOAR layer and Gemini features. This guide explains how access works, which roles and service accounts carry real power, how to run detections as code, and the hardening and monitoring baseline that keeps the SOC's own tooling from becoming the weak point. It is written for SecOps, detection engineering and cloud security teams. For SIEM concepts in general, see the SIEM Guide.

Key takeaways

• Access is now Google Cloud IAM. Feature access is granted with predefined roles such as roles/chronicle.admin, roles/chronicle.editor and roles/chronicle.viewer on the project bound to the instance, and data access is narrowed with data RBAC scopes and labels.
• Feeds and API clients are non-human identities. Every ingestion feed holds a credential for a cloud bucket, queue or SaaS API, and every detection-as-code pipeline holds a Chronicle API identity. Inventory and rotate them like any privileged account.
• Prefer Workload Identity Federation to service account keys. Google's own content manager tool documents Application Default Credentials as the default and recommends short-lived federation for CI/CD over long-lived JSON keys.
• Treat rules as code. YARA-L rules have revisions, a test function, deployment state (enabled, alerting, archived, run frequency) and an API, so they belong in a reviewed repository, not edited live in the console.
• Watch the watchers. Log and alert on changes to rules, feeds, data access scopes, reference lists and SOAR playbooks, because an attacker who can disable a rule or a feed blinds the SOC quietly.

Platform architecture: UDM, ingestion and retention

Google SecOps parses raw logs into the Unified Data Model, a common schema in which every event describes who did what to whom. Rules, search and dashboards all query UDM fields.

• Events and entities: UDM events record activity at a point in time (a login, a process launch, an API call). Entity data describes users, assets, files and resources, and is used to enrich and join events in rules.
• Nouns: principal is the actor, target the object acted on, src the source in a transfer, observer the system that reported the event, intermediary a proxy or relay, and about an entity the event concerns. Outcome fields sit under security_result (for example security_result.action = "ALLOW").
• Metadata: metadata.log_type names the source (such as GCP_CLOUDAUDIT) and metadata.event_type the activity class. Google's community style guide asks rule authors to filter on metadata.event_type wherever possible for performance.
• Ingestion paths: data arrives through the Google Cloud direct integration, forwarders and collection agents, and API-based feeds. The Chronicle API feed resource supports source types including GOOGLE_CLOUD_STORAGE, AMAZON_SQS, AZURE_BLOBSTORE, PUBSUB, AMAZON_KINESIS_FIREHOSE, AZURE_EVENT_HUB, HTTPS_PUSH_WEBHOOK and third-party API feeds.
• Parsers: Google maintains several hundred default parsers, extended with custom parsers. A parser change can silently empty a field a rule depends on, so test parser updates against detections.
• Retention: Google's product page states that packages include one year of security telemetry retention (12 months of hot data) at no additional cost. The Data Export API, generally available on the v1 endpoint since May 2026, exports to a customer-controlled Cloud Storage bucket for longer archival. Align this with your own retention policy; see the Log Management and Retention Guide.

How identity and access work in Google Security Operations

A Google SecOps instance is bound to a Google Cloud project. Access is evaluated in two layers: feature access (what a user or service can do) through Google Cloud IAM roles and permissions, and data access (which data they can see) through data RBAC. Older instances used a legacy RBAC model; Google documents a migration to IAM-based feature RBAC, which should be finished rather than run alongside.

• Workforce sign-in: analysts authenticate through Google Cloud identity, either Cloud Identity accounts or Workforce Identity Federation with a third-party identity provider. Enforce phishing-resistant MFA at the identity provider; the SIEM inherits whatever assurance the IdP gives it.
• Data RBAC scopes: a data access scope lists allowed and denied data access labels. In the API definition, allowed labels are combined with OR and denied labels with AND, and a scope can use allow_all with denied labels to grant everything except labelled data. From September 2026 direct ingestion adds a gcp_organization_id label usable in scopes.
• Restricted roles: roles/chronicle.restrictedDataAccess grants access governed by data access scopes and is intended to be refined with IAM Conditions; roles/chronicle.globalDataAccess grants access to all data. Assign one or the other deliberately.
• Exports follow the creator: since May 2026, Data Export API jobs inherit the data RBAC scope of the user who creates them.

See the Google Cloud IAM and Service Accounts Guide for IAM fundamentals.

Admin roles and privileged access

The predefined roles below come from Google Cloud's IAM role reference for the Chronicle API. Several are marked Beta there; check the current reference before building policy on them.

• Project-level IAM is also SOC access: roles/owner or roles/resourcemanager.projectIamAdmin on the bound project can grant any Chronicle role. Include the project's IAM policy in privileged access reviews.
• Separate authoring from approval: people who write rules should not be the only ones able to deploy or disable them. Use a pipeline with review in place of direct editor access for most engineers.
• Break-glass: keep one or two monitored emergency admin accounts with vaulted credentials. See the Privileged Access Management Guide.

Integrations, API tokens and service accounts

Each integration below is a non-human identity with a credential, an owner and a blast radius.

• Keys versus federation: Google's content manager documentation supports a SERVICE_ACCOUNT_KEY mode but recommends Workload Identity Federation to avoid long-lived keys. Where an organisation policy can block key creation (iam.disableServiceAccountKeyCreation), apply it to the SOC project. See the Google Cloud Organization Policy Guide.
• OAuth scopes: Chronicle API clients use the chronicle, chronicle.readonly or cloud-platform scopes. Google announced in September 2026 that write permissions are removed from chronicle.readonly from 25 January 2027, so tools that wrote under the read-only scope will break and should be moved now.
• Legacy APIs: Google deprecated the legacy Backstory and Ingestion APIs in July 2026; new instances from 26 October 2026 do not support them and all legacy endpoints are due to fail from 20 July 2027. Legacy integrations often still use old credential files, so the migration is also a credential clean-up.
• Inventory: see the Service Account Security Guide and the Secrets Management Guide.

The Okta support system breach shows why service accounts tied to security-relevant systems need their own detections: the attacker used a support service account whose credentials had been saved in an employee's personal browser profile, and a bulk download of the user list was only identified later.

YARA-L detections, curated detections and detection as code

YARA-L 2.0 is Google SecOps' rule language. It shares a name and style with file-scanning YARA but runs over UDM events and entities, not file bytes; for file content rules see the YARA Rules Guide.

• Rule sections: meta (author, description, ATT&CK mapping, severity), events (field conditions and placeholder variables), match (grouping variables over a time window, for example $sa_key_id over 1h), outcome (computed fields such as $risk_score, count_distinct(), array_distinct()) and condition.
• Rule types: the API classifies rules as SINGLE_EVENT or MULTI_EVENT. Package limits on the number of each type differ by edition and have changed during 2026, so check the current limits before planning a large custom library.
• Run frequency and state: deployments run LIVE, HOURLY or DAILY, can be enabled with or without alerting, and can be archived. Execution state can show LIMITED (execution not guaranteed) or PAUSED, which is worth alerting on.
• Reference lists and data tables: rules match against lists with the in %list_name syntax; lists support plain string, regex and CIDR syntax. An allowlist such as %kms_decryption_service_account_allowlist is a detection control in its own right, so changes to it need review.
• Retrohunt: run a rule over historical data to test it or to hunt for newly published indicators across retained telemetry. See the Threat Hunting Guide.
• Curated detections: Google-maintained rule packs, including Applied Threat Intelligence and Mandiant Frontline Threats packs. In October 2026 Google moved Applied Threat Intelligence curated rules to the GTI_IOC feed, and custom rules referencing MANDIANT_ACTIVE_BREACH_IOC, MANDIANT_FUSION_IOC or OPEN_SOURCE_INTEL_IOC need updating before those feeds are removed after 18 March 2027.
• Detection as code: the Chronicle API exposes rule creation, VerifyRuleText, revisions, deployments and retrohunts, and Google's open-source content manager and Terraform providers (announced October 2026 for feeds, parsers, rules and data export) manage rules, reference lists and data tables from a repository. See the Detection Engineering Guide.

Google's public community rules include identity-focused detections worth adopting early, for example service account key created or uploaded, service account key used from multiple countries, admin roles added to service accounts, workload identity pool disabled or deleted, and audit logging removed. These map to ATT&CK T1098.001 Additional Cloud Credentials, T1552.004 Private Keys and T1078.004 Cloud Accounts.

SOAR and Gemini in Google SecOps

• SOAR playbooks act with real privilege: Google lists over 300 SOAR integrations. A playbook that disables an account or isolates a host runs with the integration's credential, so restrict who can edit playbooks (roles/chronicle.soarAdmin) and require approval steps for destructive actions. See the SOAR and Security Automation Guide.
• Playbook version control: GitSync keeps SOAR content in a repository; Google notes that from version 53.0 it uses the Chronicle REST API with IAM authentication, so plan the migration and its credential change.
• Gemini features: Google describes natural language search, an investigation assistant, case summaries and help creating detections and playbooks. Generated rules need the same review as human-written ones. Since July 2026 Google meters generally available security agents with Security Tokens, so set consumption alerts. See the AI Agent Observability and Incident Response Guide.

Logging and detection

Monitor the SOC platform through Google Cloud Audit Logs on the bound project (Admin Activity is always on; enable Data Access logs for the Chronicle API where your volume allows) and ingest those logs back into Google SecOps or a separate store the SOC admins cannot alter.

Metrics that show it is working:

• Percentage of rules deployed from the repository (target 100 percent of custom rules).
• Standing chronicle.admin and dataGovernor holders.
• Feed credentials past their rotation date, and feeds authenticated with long-lived keys.
• Log sources with no events in 24 hours, and mean time to detect a silent source.
• Rules in LIMITED or PAUSED execution state, and rules with zero detections in 90 days reviewed for relevance.

See the Security Operations Metrics Guide.

Hardening baseline and rollout

1. Inventory first: export the bound project's IAM policy, all feeds with credential types, all rules with deployment state, SOAR integrations and remote agents. Note who owns each.
2. Finish the RBAC migration: move from legacy RBAC to IAM feature roles, map each team to a predefined or custom role, and remove direct project owner grants from analysts.
3. Introduce data RBAC in a pilot: create scopes for one business unit or tenant, assign restrictedDataAccess to a pilot group, and verify search, rules and dashboards behave as expected before widening. Roll back by reassigning global access to the pilot group.
4. Replace keys: move CI/CD and scripts to Workload Identity Federation, then block service account key creation on the project. Re-issue cloud feed credentials as dedicated read-only principals.
5. Move rules into a repository: pull existing rules with the content manager, add review and VerifyRuleText or test-rule checks in CI, and deploy new rules first as non-alerting, then enable alerting after a tuning period. Roll back by redeploying the previous revision.
6. Deploy self-monitoring rules: alert on the signals in the table above, routed to a group that includes someone outside the SOC admin team.
7. Review quarterly: role holders, feed credential age and retention against policy.

Small versus large organisations: a small team with two admins can manage rules in the console if it keeps MFA, no service account keys and alerts on rule and feed changes. Multi-tenant or regulated operations need data RBAC scopes, peer-reviewed detection as code and separate instances per regulatory boundary.

Common misconfigurations

• Analysts with project owner: granted at onboarding and never removed, so any analyst can grant themselves any role.
• One feed credential for many sources: a single cloud access key with broad read permissions shared across feeds, so one leak exposes far more than logs.
• Rules edited in production: no repository, no review, and no record of why a rule was weakened or archived.
• Allowlists that grow forever: reference list exclusions added for noisy alerts and never revisited, often covering service accounts that are later compromised.
• No alert on source silence: a parser or feed failure removes a log type for weeks while rules appear healthy, because a rule with no input raises no error.

Framework mapping

Practitioner checklist

• Map every user and group to a predefined or custom roles/chronicle.* role and remove project owner from analysts.
• Limit chronicle.admin, dataGovernor and soarAdmin to named people with time-bound elevation and quarterly review.
• Decide global versus restricted data access per team and pilot data RBAC scopes before rolling out.
• Inventory every feed credential with owner, scope and rotation date; use one least-privilege principal per feed.
• Move API automation to Workload Identity Federation and block service account key creation on the SOC project.
• Migrate tools off the legacy APIs and off write use of the chronicle.readonly scope before the published cut-off dates.
• Manage YARA-L rules, reference lists and data tables in a reviewed repository with CI checks; deploy as non-alerting first.
• Update custom rules that reference legacy Mandiant or open-source IOC feeds to GTI_IOC.
• Alert on rule, feed, scope, reference list, IAM and export changes, and on log sources going silent.
• Require approvals in SOAR playbooks for destructive actions and vault integration credentials.

Standards and references

• Google Cloud: Chronicle API roles and permissions
• Google Cloud: Google Security Operations release notes
• Google: Chronicle API v1 service definitions
• Google: Google Security Operations detection rules and content manager
• Google Cloud: Google Security Operations product overview
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• CIS: CIS Controls v8.1

Related NHI Mgmt Group resources: SIEM Guide · Detection Engineering Guide · Google Cloud Security Guide · Service Account Security Guide · SOAR Buyer's Guide