Synqly’s Google SecOps Integration: What Product and Engineering Teams Need to Know
Building a SOC integration takes longer than it should. Most engineering teams spend weeks, sometimes months, mapping data schemas, wiring up API calls, handling auth flows, and keeping everything working as vendors update their platforms. That time does not go toward your core product. It goes toward plumbing. Synqly’s Google Security Operations integration changes that equation for product and engineering teams looking to deliver the integrations their customers need without relying on internal development or outsourcing.
Two Integration Modes, Built for Different Use Cases
The Google Security Operations integration ships in two configurations: SOC platform and Sink. Both sit behind Synqly’s unified API. The difference is scope.
The SOC platform integration gives you full bi-directional access to Google Security Operations . You can push event data in, query it back out, pull alerts, and enumerate available log types. This is the right choice for product teams who need to read from and write to Google Security Operations as part of a detection, response, or analytics workflow.
The Sink integration is scoped to event ingestion only. If your product collects security telemetry and needs to forward it to a customer’s Google Security Operations instance, the Sink configuration covers that without requiring the broader SOC platform permission set.
Both configurations use Google Security Operations’ modern customer-credentialed Chronicle APIs. This is not the legacy Chronicle compatibility layer. Customers provision a Google Cloud service account, collect their Customer ID, Region, and Project ID from the Google Cloud console, and supply those values to Synqly. Synqly automatically constructs the correct region-specific endpoint.
The API Surface
Once connected, Synqly exposes the following operations through its unified API:
- PostEvents pushes raw event data into Google Security Operations for ingestion and downstream processing. You call Synqly’s API. Synqly handles the transformation and delivery to Google Security Operations.
- QueryEvents retrieves event data from Google Security Operations at scale. Run searches against ingested telemetry without writing UDM-specific query logic yourself.
- QueryLogProviders returns the list of available log type values for a given Google Security Operations instance. This is useful when building dynamic integrations that need to reflect the actual log sources a customer has configured.
- QueryAlerts surfaces active alerts from Google Security Operations in real time. Feed those alerts into your response workflows, dashboards, or orchestration logic.
- GetAlert retrieves the full detail record for a single alert by ID. Use this when you need to enrich or act on a specific detection without pulling the entire alert set.
These operations map to Synqly’s standard SOC platform integration interface, meaning the same code that works with Google Security Operations today will work with other SOC platform providers in Synqly’s catalog without rework.
Schema Normalization: UDM and OCSF
This is where most teams spend the most time when building SOC platform integrations manually.
Google Security Operations uses Unified Data Model (UDM) as its native schema. UDM is expressive and well-suited to Google’s detection and analytics engine. However, it is not the schema that most security products work in natively. The Open Cybersecurity Schema Framework (OCSF) has emerged as the cross-vendor standard for security event data. Many security products, data pipelines, and platforms now produce and consume OCSF natively.
Synqly performs bi-directional normalization between UDM and OCSF automatically. Your product sends and receives OCSF-formatted data. Synqly translates to and from UDM as needed to interact with Google Security Operations. You do not write field mappings. You do not maintain a translation layer. Synqly owns that work.
This matters at scale. A single schema change in Google Security Operations’ UDM definition could require updates across every product that built its own connector. With Synqly, that update happens once, in one place, and every customer inherits it.
Security by Default: Least-Privilege IAM Setup
The SOC platform integration requires three Chronicle IAM permissions:
chronicle.events.import(can be omitted if not using event ingestion)chronicle.events.udmSearchchronicle.logTypes.listchronicle.legacies.legacySearchDetectionschronicle.legacies.legacyGetDetection
The Sink integration requires only chronicle.events.import.
Synqly’s setup guides walk through creating a custom IAM role scoped to exactly these permissions, so customers are not forced to use the Chronicle API Admin role when a more limited role fits their needs. Security teams should operate on least-privilege principles, and Synqly’s integration supports that from the start.
Synqly’s full setup documentation can be found here:
What This Means for Your Product Roadmap
Security product teams face constant pressure to expand the list of SOC platforms their product supports. Each new SOC platform is a project: auth patterns to learn, schemas to map, API quirks to handle, and a connector to maintain indefinitely.
Synqly changes that model. You write to one API. Synqly handles the integration surface for every provider in its catalog, including Google Security Operations. When Google Security Operations updates its APIs or extends UDM, Synqly handles that change, and your product keeps working.
For product teams, that means a faster time-to-market for SOC platform support. For engineering teams, that means fewer interruptions from connector maintenance. For customers, that means a product that reliably supports the security stack they already run.
The Google Security Operations integration is available now to all Synqly customers. To get started, visit synqly.com/demo or head directly to the Synqly documentation.