.png)
Google Security Operations Integration Guide
Connect Google Security Operations with enterprise systems through Google Cloud REST APIs, UDM Search, ingestion services, and selected SOAR notifications.
Google Security Operations integration options at a glance
Google Security Operations provides a REST-first integration surface for ingesting UDM-formatted security events, searching normalized security data, retrieving detections and alerts, managing reference lists, and accessing selected SOAR resources. Batch and asynchronous ingestion patterns support higher-volume telemetry, while UDM Search enables scheduled or on-demand investigation workflows. Webhook-style notifications may be available for selected alerting, SOAR, or automation scenarios, but universal object-level coverage should not be assumed. Martini can authenticate with Google Cloud OAuth 2.0 and IAM, transform source data into UDM structures, orchestrate searches and downstream actions, and apply checkpointing, retries, and idempotency controls.
| Integration point | Supported by Google Security Operations? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Ingest UDM events, search security data, retrieve detections and alerts, manage reference lists, and access selected cases or SOAR resources. | Martini can consume documented Google Security Operations REST APIs, handle regional endpoints and resource names, transform responses, and orchestrate downstream workflows. |
| UDM Search API | Yes | Run time-bounded searches for authentication activity, detection trends, privileged access, asset activity, or investigation evidence. | Martini can invoke searches on demand or on a schedule, process pagination and cursors, apply checkpoints, and deliver normalized results to target systems. |
| Event ingestion APIs | Yes | Submit security telemetry through supported ingestion services using UDM-formatted events and documented source-specific ingestion paths. | Martini can validate and map source payloads to UDM structures, batch events within endpoint limits, record responses, and retry transient failures. |
| Bulk and batch ingestion | Limited | Ingest higher-volume telemetry using supported event batches or asynchronous collection patterns. | Martini can group events, control payload size and concurrency, capture batch errors, and separate retryable failures from invalid records. |
| Webhooks and outbound callbacks | Limited | Receive selected alerting, SOAR, or automation notifications where the specific Google Security Operations feature provides a documented callback mechanism. | Martini can expose or consume a workflow endpoint for confirmed callback scenarios, but integrations should not assume universal webhook coverage. |
| Database and analytics access | Limited | Use UDM Search as an API-based analytics interface rather than connecting directly to a Google Security Operations database. | Martini can execute parameterized searches, process pages and time windows, and route results to reporting, warehouse, or case-management workflows. |
| Authentication | Yes | Authenticate server-to-server requests with Google Cloud OAuth 2.0 access tokens, service accounts, workload identity, and IAM permissions. | Martini can keep credentials, scopes, regional configuration, and resource identifiers in secure environment configuration and use them in API workflows. |
| SOAP APIs | No | The documented Google Security Operations integration surface is REST and Google Cloud service based; SOAP is not a recommended mechanism. | Martini can consume SOAP services generally, but this is not an applicable Google Security Operations integration method based on the supplied research. |
How Google Security Operations exposes data and business events
Google Security Operations REST APIs
REST is the primary documented integration mechanism for Google Security Operations. It supports event ingestion, UDM searches, detection and alert access, reference-list operations, and selected SOAR resources. Available resources and API versions vary by service, edition, and regional configuration.
Martini implementation pattern
Martini implementation pattern: A Martini workflow authenticates with Google Cloud OAuth 2.0, calls the appropriate regional endpoint, validates the response, maps data to the target model, and records checkpoints or identifiers for reliable synchronization.
Implementation sequence
UDM Search
UDM Search provides API-based query access to normalized security events. It can support time-bounded investigations, operational reports, detection analysis, and exports of selected results, subject to query syntax, permissions, quotas, pagination, and regional configuration.
Martini implementation pattern
Martini implementation pattern: A scheduled or on-demand workflow submits a bounded search, follows documented page tokens or cursors, transforms results, and delivers them to a reporting API, warehouse, case system, or controlled file output.
Implementation sequence
Event ingestion and batch APIs
Google Security Operations supports ingestion of security telemetry through documented ingestion services and supported batch patterns. Source data generally must be mapped to the Unified Data Model rather than submitted as arbitrary JSON.
Martini implementation pattern
Martini implementation pattern: Martini receives source logs through a supported API, file, queue, or scheduled extraction, validates required fields, maps them to UDM event structures, submits compliant batches, and handles partial or transient failures.
Implementation sequence
Selected notifications and callbacks
Google Security Operations may provide webhook-style or callback mechanisms for selected alerting, SOAR, or automation scenarios. A general-purpose webhook for every object and event type should not be assumed.
Martini implementation pattern
Martini implementation pattern: Where a specific feature documents an outbound callback, Martini receives the notification through an API workflow, verifies and retrieves the current resource when appropriate, and uses the event identifier to prevent duplicate processing. Broad synchronization should use APIs or scheduled queries instead.
Implementation sequence
Common Google Security Operations integration patterns
Pattern 1: Ingest application and infrastructure logs
When to use this pattern
Use this pattern when application, cloud, endpoint, or enterprise-platform telemetry must be normalized in Google Security Operations for detection and investigation. It is appropriate for API, queue, file, or scheduled source collection where the source payload does not already match UDM.
Integration direction
Example Mapping
| Google Security Operations Field | Canonical Field | Target Field |
|---|---|---|
| source_event_id | event.id | UDM metadata.event_id |
| event_timestamp | event.occurred_at | UDM metadata.event_timestamp |
| user_name | principal.user.userid | UDM principal.user.userid |
| source_ip | network.source.ip | UDM principal.ip |
Martini implementation pattern
Martini receives or retrieves source events, validates required fields and timestamps, maps event types and enumerations to UDM, applies source-specific business rules, submits bounded batches, and stores source identifiers. Invalid records are routed for correction while transient API or quota failures are retried with backoff.
Martini capabilities used
- workflows
- API consumption
- data mapping
- JSON handling
- business rules
- error handling
Pattern 2: Route detections to incident management
When to use this pattern
Use this pattern when detections or alerts in Google Security Operations should create or update incidents in ServiceNow, Jira, or an internal response API. It supports enrichment, severity rules, deduplication, and selected status synchronization.
Integration direction
Example Mapping
| Google Security Operations Field | Canonical Field | Target Field |
|---|---|---|
| detection_id | finding.external_id | ServiceNow correlation_id |
| alert_name | finding.title | ServiceNow short_description |
| severity | finding.priority | ServiceNow priority |
| asset | affected_asset | ServiceNow configuration_item |
Martini implementation pattern
A scheduled Martini workflow queries a bounded time range, follows pagination, enriches findings with identity or asset data, applies severity and routing rules, and creates or updates incidents. A durable identifier prevents duplicates, while transient downstream failures are retried and validation failures are isolated.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- data enrichment
- business rules
- idempotency
- retry handling
Pattern 3: Produce UDM investigation reports
When to use this pattern
Use this pattern for daily authentication summaries, privileged-access reports, detection trends, asset activity, or investigation evidence exported from UDM Search.
Integration direction
Example Mapping
| Google Security Operations Field | Canonical Field | Target Field |
|---|---|---|
| metadata.event_timestamp | activity.occurred_at | report.event_time |
| principal.user.userid | actor.identifier | report.actor |
| security_result.action | outcome.action | report.result |
| metadata.event_type | activity.type | report.event_type |
Martini implementation pattern
Martini starts on a schedule, executes a bounded UDM query with an overlap window, retrieves all pages, normalizes and aggregates results, applies reporting filters, and writes to a warehouse or reporting endpoint. Checkpoints and stable event identifiers prevent omissions and duplicate exports.
Martini capabilities used
- scheduler triggers
- workflow orchestration
- API consumption
- mapping and transformation
- aggregation
- checkpointing
- monitoring
Pattern 4: Synchronize threat-intelligence reference lists
When to use this pattern
Use this pattern when indicators or watchlists from a threat-intelligence or vulnerability platform should update Google Security Operations reference lists, or when selected list values must be distributed to other security systems.
Integration direction
Example Mapping
| Google Security Operations Field | Canonical Field | Target Field |
|---|---|---|
| indicator_value | indicator.value | Reference list value |
| indicator_type | indicator.kind | Reference list classification |
| confidence | indicator.confidence | Enrichment metadata |
| expires_at | indicator.expiry | Reference list lifecycle |
Martini implementation pattern
Martini retrieves source indicators, validates formats and expiry, normalizes values, compares the desired set with the current list where supported, and updates Google Security Operations using the applicable API and IAM permissions. The workflow records changes and avoids retrying permanent validation errors.
Martini capabilities used
- workflows
- API consumption
- data mapping
- set comparison
- business rules
- secrets management
- error handling
Applications commonly integrated with Google Security Operations
Google Security Operations can be connected to security, identity, ITSM, cloud, and collaboration products through their documented APIs or supported event mechanisms. These scenarios are architecture patterns rather than claims of universal first-party integrations.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| ServiceNow | Create and update incidents from detections or alerts, synchronize assignment and status, and link findings to ITSM records. | Google Security Operations → Martini → ServiceNow | Martini queries or receives supported Google Security Operations findings, deduplicates them by stable identifiers, maps them to ServiceNow incidents, and optionally processes status updates in the reverse direction. |
| Jira | Create investigation or remediation issues from security findings and track engineering response. | Google Security Operations → Martini → Jira | A scheduled Martini workflow searches detections or alerts, enriches them with context, creates Jira issues, and synchronizes selected workflow states using checkpoints and retry handling. |
| CrowdStrike Falcon | Correlate endpoint detections with Google Security Operations events and enrich investigations with host or process context. | CrowdStrike Falcon → Martini → Google Security Operations | Martini retrieves selected CrowdStrike Falcon findings, maps endpoint and process data to UDM fields, validates required values, and submits supported event batches to Google Security Operations. |
| Microsoft Sentinel | Exchange selected alerts or events during a multi-SIEM, migration, or consolidation program. | Google Security Operations → Martini → Microsoft Sentinel | Martini reads selected detections or alerts, applies filtering and normalization, and forwards only the required security findings to Sentinel while preserving source identifiers for deduplication. |
| Okta | Enrich investigations with identity, sign-in, user, and administrative activity data. | Okta → Martini → Google Security Operations | Martini retrieves relevant Okta activity, maps identity and authentication attributes to UDM structures, and submits validated events or enrichment data through the documented Google Security Operations APIs. |
| Palo Alto Cortex XDR | Correlate endpoint and network security findings with Google Security Operations detections. | Palo Alto Cortex XDR → Martini → Google Security Operations | A Martini workflow polls or receives supported Cortex XDR data, normalizes host and detection fields, applies event-type rules, and ingests the resulting UDM events with controlled batching. |
| Google Cloud | Correlate Google Cloud audit, IAM, network, and workload activity with security detections. | Google Cloud → Martini → Google Security Operations | Martini consumes available Google Cloud security telemetry APIs or exports, transforms the data to the required UDM representation, and submits events using a least-privilege service account. |
| Google Workspace | Bring administrator, authentication, and user activity into security investigations. | Google Workspace → Martini → Google Security Operations | Martini retrieves selected Workspace activity, validates timestamps and identity fields, maps the payload to UDM event types, and sends supported batches to Google Security Operations. |
How to build a Google Security Operations integration in Martini
Objective
Establish the Google Security Operations connection with regional and customer-specific configuration separated from workflow logic.
Instructions in Martini
- Configure the regional endpoint, customer or instance identifier, scopes, and resource names as environment values.
- Use Google Cloud OAuth 2.0 with a service account or supported workload identity.
- Store credentials and sensitive configuration in Martini secrets.
- Grant only the IAM permissions required by each workflow.
Objective
Select a trigger that matches the synchronization requirement and the confirmed Google Security Operations capability.
Instructions in Martini
- Use a scheduler for UDM searches, polling, reports, and reliable synchronization.
- Use a Martini API or callback workflow only when the specific Google Security Operations feature documents notifications.
- Use an approved source API, file, or queue trigger for event ingestion.
Objective
Collect events, detections, alerts, cases, assets, or reference-list values with bounded requests.
Instructions in Martini
- Use documented REST resources and UDM Search queries.
- Apply time windows, filters, pagination, and page-token handling.
- Preserve source identifiers, cursors, and checkpoints between runs.
- Do not treat all detections, alerts, and cases as interchangeable.
Objective
Coordinate calls, enrichment, routing, and response actions in a maintainable Martini workflow.
Instructions in Martini
- Separate retrieval, validation, transformation, target writes, and error paths.
- Enrich findings with identity, asset, or ticketing data when required.
- Apply conditional routing based on severity, event type, source, or business ownership.
- Use reusable workflow logic for common API and error-handling behavior.
Objective
Convert source payloads into UDM or downstream application models without losing identifiers or security context.
Instructions in Martini
- Map timestamps, principals, targets, IP addresses, event types, outcomes, and vendor metadata explicitly.
- Validate required UDM fields and enumerated values before ingestion.
- Normalize identifiers, severity, status, and time zones.
- Preserve the original source identifier for traceability and deduplication.
Objective
Control which findings, events, and list values should be processed and how they should be routed.
Instructions in Martini
- Filter low-value or out-of-scope events before downstream processing.
- Apply severity and ownership rules for incident creation.
- Use overlap windows for delayed ingestion and clock skew.
- Prevent duplicate incidents and repeated reference-list updates with stable keys.
Common Google Security Operations data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| UDM events | Normalized authentication, network, process, DNS, file, and other security activity submitted for search and detection. | Google Security Operations, data warehouses, reporting platforms, and security analytics systems | Martini validates timestamps, entities, enumerations, metadata, and event types, maps source payloads to UDM, batches events, and records ingestion results. |
| Detections | Findings generated when detection rules match UDM events. | ServiceNow, Jira, case-management platforms, messaging tools, and incident APIs | Martini retrieves detections through documented APIs, enriches and normalizes them, applies deduplication, and routes actionable findings. |
| Alerts | Security findings presented for investigation and response. | ITSM platforms, incident-response systems, Microsoft Sentinel, and notification services | Martini uses stable identifiers and checkpoints to avoid duplicate downstream incidents, maps severity and context, and synchronizes selected status data. |
| Cases | SOAR investigation and response containers grouping alerts, entities, tasks, and response activity. | Case-management systems, ITSM platforms, reporting systems, and security operations tools | Martini accesses cases only through the relevant API and permissions, transforms case relationships, and preserves identifiers across systems. |
| Assets | Hosts, users, devices, applications, and other entities involved in investigations. | CMDBs, identity platforms, endpoint tools, ITSM platforms, and data warehouses | Martini enriches detections or events with asset context, normalizes identifiers, and applies matching rules before writing to targets. |
| Reference lists | Managed values used by detection rules, enrichment logic, filtering, and threat-intelligence workflows. | Threat-intelligence platforms, vulnerability tools, security analytics systems, and internal watchlist services | Martini normalizes values, compares versions or hashes where available, and updates or distributes list contents when the relevant API and permissions support it. |
Authentication and security considerations
OAuth 2.0 and IAM
Google Security Operations uses Google Cloud OAuth 2.0 bearer tokens and IAM-controlled permissions. Service accounts or supported workload identity are appropriate for server-to-server workflows.
Least privilege
Use separate integration identities or permissions for searching, ingestion, detection access, reference-list management, and SOAR operations where practical.
Environment configuration
Keep regional endpoints, customer or instance identifiers, scopes, resource names, and credentials in Martini environment configuration and secrets rather than workflow logic.
Data protection
Security events may include usernames, hostnames, IP addresses, email addresses, and command lines. Restrict workflow logs, protect credentials, minimize payload exposure, and apply appropriate retention controls.
Operational considerations for Google Security Operations integrations
Quotas and retries
Google Cloud APIs are quota-controlled. Use bounded concurrency, request-size controls, exponential backoff, and monitoring for 429 and 5xx responses. Do not blindly retry non-idempotent operations.
Pagination and time windows
Preserve page tokens or cursors and use bounded, overlapping time windows for UDM and detection searches. Overlap helps account for delayed ingestion and clock skew, while stable identifiers prevent duplicate processing.
UDM validation
Validate event types, timestamps, principals, targets, IP addresses, outcomes, metadata, and enumerated values before ingestion. Invalid or incomplete mappings can reduce searchability or cause ingestion failures.
Schema and API evolution
Pin the API version used by the integration, monitor Google Security Operations documentation for deprecations, tolerate additive fields, and detect changed resource names or unknown enumerations.
Testing and observability
Test representative ingestion, search, pagination, partial failure, permission, and duplicate scenarios. Monitor workflow outcomes, quota failures, rejected events, retries, and downstream write status.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond scripts
Martini coordinates API calls, scheduled searches, ingestion, enrichment, downstream writes, and response handling in maintainable workflows rather than isolated scripts.
Controlled transformation
Martini provides explicit mapping, validation, and business-rule stages for converting source telemetry into UDM and translating detections into ITSM or response-system models.
Reliability and reuse
Reusable workflow assets can standardize authentication, pagination, checkpointing, idempotency, retries, and error routing across multiple Google Security Operations integrations.
Governed APIs
Martini can expose controlled API façades that centralize authorization and vendor-specific logic while protecting Google Cloud credentials and regional configuration from consuming applications.
Frequently asked questions
Google Security Operations can be integrated through Google Cloud REST APIs, UDM Search, supported event-ingestion services, batch or asynchronous ingestion patterns, and selected notification or SOAR callback mechanisms. OAuth 2.0, service accounts, workload identity, and IAM provide the normal authentication model. Enterprise workflows commonly ingest normalized telemetry, query detections and alerts, enrich investigations, update reference lists, and route findings to ITSM or response systems.
Yes. Martini can consume Google Security Operations REST APIs, run UDM searches, submit transformed UDM events through supported ingestion endpoints, and orchestrate downstream systems. It can also process a documented callback or notification for a specific alerting or SOAR scenario, subject to that feature's coverage and permissions.
No. A dedicated Google Security Operations connector is not required. Martini can use the vendor's confirmed native REST APIs, UDM Search, ingestion services, OAuth 2.0 and IAM authentication, and selected callback mechanisms through API-led workflows.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Google Security Operations. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Google Cloud, Google Security Operations, infrastructure providers, or other third-party systems based on subscription, usage, and deployment model.
REST APIs and documented ingestion services are the primary methods. UDM Search is appropriate for investigation, reporting, and scheduled synchronization, while batch ingestion supports higher-volume telemetry within documented limits. Webhook-style callbacks should be used only for specifically confirmed alerting, SOAR, or automation features; GraphQL and SOAP were not confirmed as Google Security Operations methods.
Selected notification or SOAR scenarios may provide webhook-style or callback behavior, but Google Security Operations does not provide a confirmed universal webhook model for every object and event. For broad synchronization, use documented APIs or scheduled UDM and detection queries, with checkpoints and idempotency controls.
Martini can poll bounded time windows, follow pagination, preserve cursors, and use overlapping windows to account for delayed ingestion. For ingestion, source data must be mapped to the required UDM event structure rather than submitted as arbitrary JSON. Martini can transform timestamps, entities, event types, enumerations, outcomes, and identifiers before writing to Google Security Operations or downstream systems.
A robust workflow separates authentication failures, invalid UDM data, quota responses, temporary service errors, missing resources, and already-processed records. Martini can retry transient 429 and 5xx responses with exponential backoff, isolate validation failures, and persist detection, alert, case, or event identifiers as idempotency keys to avoid duplicate downstream incidents.
Yes. Martini can expose a controlled API that accepts approved requests, invokes Google Security Operations REST APIs or UDM searches, applies authorization and business rules, and returns a governed response. This can shield consumers from regional endpoints, Google Cloud credentials, resource naming, pagination, and vendor-specific data models.
Related Martini documentation
Workflows
Transformation
Operations
Connect Google Security Operations with your enterprise systems
Use Martini to build governed, resilient Google Security Operations integrations for security telemetry ingestion, UDM search, detection routing, and SOAR workflows.